[PATCH] rtlwifi: rtl8192cu: remove check for CONFIG_AUTOSUSPEND
A check for CONFIG_AUTOSUSPEND was included in this driver when it was
added in v2.6.39. But that Kconfig symbol doesn't exist. Remove that
check and the single line it hides.
Signed-off-by: Paul Bolle
---
Compile tested.
It's hard to say whether or not the intention was to allow enabling
usb's autosuspend functionality. But that functionality has been
disabled (as leaving this member zero probably means) for three years
now and I don't have access to this hardware. So I opted for safety.
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
index c61311084d7e..361435f8608a 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -395,9 +395,6 @@ static struct usb_driver rtl8192cu_driver = {
/* .resume = rtl_usb_resume, */
/* .reset_resume = rtl8192c_resume, */
#endif /* CONFIG_PM */
-#ifdef CONFIG_AUTOSUSPEND
- .supports_autosuspend = 1,
-#endif
.disable_hub_initiated_lpm = 1,
};
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: Silicom: bpctl_mod.c: Fixed a lot of checkpatch.pl warnings
Forgot to add - what went wrong - I had deleted some whitespaces which made the git apply mad. Thanks, Chaitanya On Fri, May 23, 2014 at 10:32 PM, Chaitanya Hazarey wrote: > Thanks Greg for looking into it, > > I have resubmitted using a new email, hope that works out. > > Thanks, > > Chaitanya > > On Fri, May 23, 2014 at 3:26 PM, Greg KH wrote: >> On Fri, May 23, 2014 at 02:47:10PM -0700, Chaitanya Hazarey wrote: >>> Added a blank line after declarations in many places to fix the following >>> warning issued by checkpatch.pl: >>> >>> WARNING: Missing a blank line after declarations >>> --- >>> drivers/staging/silicom/bpctl_mod.c | 90 >>> ++- >>> 1 file changed, 88 insertions(+), 2 deletions(-) >> >> Something is corrupted in this patch and it doesn't apply properly. Can >> you resend it to yourself and try to figure out what went wrong? >> >> thanks, >> >> greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: Silicom: bpctl_mod.c: Fixed a lot of checkpatch.pl warnings
Thanks Greg for looking into it, I have resubmitted using a new email, hope that works out. Thanks, Chaitanya On Fri, May 23, 2014 at 3:26 PM, Greg KH wrote: > On Fri, May 23, 2014 at 02:47:10PM -0700, Chaitanya Hazarey wrote: >> Added a blank line after declarations in many places to fix the following >> warning issued by checkpatch.pl: >> >> WARNING: Missing a blank line after declarations >> --- >> drivers/staging/silicom/bpctl_mod.c | 90 >> ++- >> 1 file changed, 88 insertions(+), 2 deletions(-) > > Something is corrupted in this patch and it doesn't apply properly. Can > you resend it to yourself and try to figure out what went wrong? > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: Silicom: Bypasslib: Fixed a couple of checkpatch.pl warnings
Hey Dan,
Thanks for your patience, I have resubmitted via a new email. Hope that works.
Thanks,
Chaitanya
On Fri, May 23, 2014 at 3:54 PM, Dan Carpenter wrote:
> On Fri, May 23, 2014 at 02:39:43PM -0700, Chaitanya Hazarey wrote:
>> Added a blank line after declarations to fix the following warnings issued
>> by checkpatch.pl:
>>
>> drivers/staging/silicom/bypasslib/bypass.c:138: WARNING: Missing a blank
>> line after declarations
>> drivers/staging/silicom/bypasslib/bypass.c:189: WARNING: Missing a blank
>> line after declarations
>>
>> Signed-off-by: Chaitanya Hazarey
>
> Still doesn't apply, I'm afraid.
>
>> ---
>> drivers/staging/silicom/bypasslib/bypass.c |2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/staging/silicom/bypasslib/bypass.c
>> b/drivers/staging/silicom/bypasslib/bypass.c
>> index a58251f..8e714a8 100644
>> --- a/drivers/staging/silicom/bypasslib/bypass.c
>> +++ b/drivers/staging/silicom/bypasslib/bypass.c
>> @@ -135,6 +135,7 @@ static int doit(int cmd, int if_index, int *data)
>> static int is_dev_sd(int if_index)
>> {
>> int ret = 0;
>> +
>> SET_BPLIB_INT_FN(is_bypass, int, if_index, ret);
>> return ret >= 0 ? 1 : 0;
>> }
>> @@ -186,6 +187,7 @@ static int is_bypass_dev(int if_index)
>> static int is_bypass(int if_index)
>> {
>> int ret = 0;
>> +
>> SET_BPLIB_INT_FN(is_bypass, int, if_index, ret);
>> if (ret < 0)
>
> There was supposed to be a blank line between the call to
> SET_BPLIB_INT_FN() and the return check and it got deleted for some
> reason.
>
> regards,
> dan carpetner
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: Silicom: bpctl_mod.c & bypass.c: Fixed a lot of checkpatch.pl warnings
Added a blank line after declarations in many places to fix the following
warning issued by checkpatch.pl:
WARNING: Missing a blank line after declarations
Thanks Greg K-H and Dan for the patience. Hope it works this time, I did apply
it against staging and it was ok.
Signed-off-by: Chaitanya Hazarey
---
drivers/staging/silicom/bpctl_mod.c| 92 +++-
drivers/staging/silicom/bypasslib/bypass.c |2 +
2 files changed, 91 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/silicom/bpctl_mod.c
b/drivers/staging/silicom/bpctl_mod.c
index 7f3d884..83f1072 100644
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@ -752,6 +752,7 @@ static void write_reg(struct bpctl_dev *pbpctl_dev,
unsigned char value,
uint32_t ctrl_ext = 0, ctrl = 0;
struct bpctl_dev *pbpctl_dev_c = NULL;
unsigned long flags;
+
if (pbpctl_dev->bp_10g9) {
pbpctl_dev_c = get_status_port_fn(pbpctl_dev);
if (!pbpctl_dev_c)
@@ -927,6 +928,7 @@ static int read_reg(struct bpctl_dev *pbpctl_dev, unsigned
char addr)
#ifdef BP_SYNC_FLAG
unsigned long flags;
+
spin_lock_irqsave(_dev->bypass_wr_lock, flags);
#else
atomic_set(_dev->wdt_busy, 1);
@@ -1563,6 +1565,7 @@ int pulse_set_fn(struct bpctl_dev *pbpctl_dev, unsigned
int counter)
int zero_set_fn(struct bpctl_dev *pbpctl_dev)
{
uint32_t ctrl_ext = 0, ctrl_value = 0;
+
if (!pbpctl_dev)
return -1;
@@ -1588,6 +1591,7 @@ int zero_set_fn(struct bpctl_dev *pbpctl_dev)
int pulse_get2_fn(struct bpctl_dev *pbpctl_dev)
{
uint32_t ctrl_ext = 0, ctrl_value = 0;
+
if (!pbpctl_dev)
return -1;
@@ -1603,6 +1607,7 @@ int pulse_get2_fn(struct bpctl_dev *pbpctl_dev)
int pulse_get1_fn(struct bpctl_dev *pbpctl_dev)
{
uint32_t ctrl_ext = 0, ctrl_value = 0;
+
if (!pbpctl_dev)
return -1;
@@ -1666,6 +1671,7 @@ static struct bpctl_dev *lookup_port(struct bpctl_dev
*dev)
{
struct bpctl_dev *p;
int n;
+
for (n = 0, p = bpctl_dev_arr; n < device_num && p->pdev; n++) {
if (p->bus == dev->bus
&& p->slot == dev->slot
@@ -1843,6 +1849,7 @@ static int bypass_off(struct bpctl_dev *pbpctl_dev)
static int tap_off(struct bpctl_dev *pbpctl_dev)
{
int ret = BP_NOT_CAP;
+
if ((pbpctl_dev->bp_caps & TAP_CAP)
&& (pbpctl_dev->bp_ext_ver >= PXG2TBPI_VER)) {
write_data(pbpctl_dev, TAP_OFF);
@@ -1856,6 +1863,7 @@ static int tap_off(struct bpctl_dev *pbpctl_dev)
static int tap_on(struct bpctl_dev *pbpctl_dev)
{
int ret = BP_NOT_CAP;
+
if ((pbpctl_dev->bp_caps & TAP_CAP)
&& (pbpctl_dev->bp_ext_ver >= PXG2TBPI_VER)) {
write_data(pbpctl_dev, TAP_ON);
@@ -1869,6 +1877,7 @@ static int tap_on(struct bpctl_dev *pbpctl_dev)
static int disc_off(struct bpctl_dev *pbpctl_dev)
{
int ret = 0;
+
if ((pbpctl_dev->bp_caps & DISC_CAP) && (pbpctl_dev->bp_ext_ver >=
0x8)) {
write_data(pbpctl_dev, DISC_OFF);
msec_delay_bp(LATCH_DELAY);
@@ -1881,6 +1890,7 @@ static int disc_off(struct bpctl_dev *pbpctl_dev)
static int disc_on(struct bpctl_dev *pbpctl_dev)
{
int ret = 0;
+
if ((pbpctl_dev->bp_caps & DISC_CAP) && (pbpctl_dev->bp_ext_ver >=
0x8)) {
write_data(pbpctl_dev, /*DISC_ON */ 0x85);
msec_delay_bp(LATCH_DELAY);
@@ -2270,6 +2280,7 @@ static int set_tx(struct bpctl_dev *pbpctl_dev, int
tx_state)
{
int ret = 0, ctrl = 0;
struct bpctl_dev *pbpctl_dev_m;
+
if ((is_bypass_fn(pbpctl_dev)) == 1)
pbpctl_dev_m = pbpctl_dev;
else
@@ -2802,6 +2813,7 @@ int wdt_time_left(struct bpctl_dev *pbpctl_dev)
static int wdt_timer(struct bpctl_dev *pbpctl_dev, int *time_left)
{
int ret = 0;
+
if (pbpctl_dev->bp_caps & WD_CTL_CAP) {
{
if (pbpctl_dev->wdt_status == WDT_STATUS_UNKNOWN)
@@ -3014,6 +3026,7 @@ static int tx_status(struct bpctl_dev *pbpctl_dev)
{
uint32_t ctrl = 0;
struct bpctl_dev *pbpctl_dev_m;
+
if ((is_bypass_fn(pbpctl_dev)) == 1)
pbpctl_dev_m = pbpctl_dev;
else
@@ -3195,6 +3208,7 @@ static int bypass_change_status(struct bpctl_dev
*pbpctl_dev)
static int bypass_status(struct bpctl_dev *pbpctl_dev)
{
u32 ctrl_ext = 0;
+
if (pbpctl_dev->bp_caps & BP_CAP) {
struct bpctl_dev *pbpctl_dev_b = NULL;
@@ -3323,6 +3337,7 @@ static int dis_bypass_cap_status(struct bpctl_dev
*pbpctl_dev)
static int wdt_programmed(struct bpctl_dev *pbpctl_dev, int *timeout)
{
int ret = 0;
+
if (pbpctl_dev->bp_caps & WD_CTL_CAP) {
if (pbpctl_dev->bp_ext_ver >= PXG2BPI_VER) {
if ((read_reg(pbpctl_dev, STATUS_REG_ADDR)) &
[PATCH] staging: Convert __FUNCTION__ to __func__
Use the normal mechanism for emitting a function name.
Signed-off-by: Joe Perches
---
drivers/staging/bcm/Qos.c | 14 -
drivers/staging/keucr/scsiglue.c | 2 +-
drivers/staging/octeon-usb/octeon-hcd.c| 2 +-
drivers/staging/rtl8192u/ieee80211/ieee80211.h | 2 +-
.../rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 2 +-
.../rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 2 +-
.../rtl8192u/ieee80211/ieee80211_crypt_wep.c | 2 +-
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 34 +++---
.../staging/rtl8192u/ieee80211/ieee80211_softmac.c | 10 +++
drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c | 2 +-
drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 2 +-
.../staging/rtl8192u/ieee80211/rtl819x_BAProc.c| 22 +++---
.../staging/rtl8192u/ieee80211/rtl819x_HTProc.c| 10 +++
.../staging/rtl8192u/ieee80211/rtl819x_TSProc.c| 10 +++
drivers/staging/rtl8192u/r8192U_dm.c | 12
drivers/staging/rtl8192u/r8192U_wx.c | 12
drivers/staging/rtl8192u/r819xU_firmware.c | 6 ++--
drivers/staging/rtl8723au/hal/hal_com.c| 4 +--
drivers/staging/rtl8723au/hal/odm.c| 4 +--
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c | 24 +++
drivers/staging/rtl8723au/hal/rtl8723a_phycfg.c| 2 +-
drivers/staging/rtl8723au/hal/rtl8723au_recv.c | 2 +-
drivers/staging/rtl8723au/hal/usb_ops_linux.c | 16 +-
.../rtl8723au/include/rtl8723a_bt-coexist.h| 2 +-
drivers/staging/rtl8723au/include/rtw_mlme_ext.h | 4 +--
.../staging/usbip/userspace/libsrc/usbip_common.h | 2 +-
26 files changed, 103 insertions(+), 103 deletions(-)
diff --git a/drivers/staging/bcm/Qos.c b/drivers/staging/bcm/Qos.c
index 64ae92b..0c742da 100644
--- a/drivers/staging/bcm/Qos.c
+++ b/drivers/staging/bcm/Qos.c
@@ -591,7 +591,7 @@ static bool EthCSMatchSrcMACAddress(struct
bcm_classifier_rule *pstClassifierRul
struct bcm_mini_adapter *Adapter = GET_BCM_ADAPTER(gblpnetdev);
if (pstClassifierRule->ucEthCSSrcMACLen == 0)
return TRUE;
- BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, "%s\n",
__FUNCTION__);
+ BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, "%s\n",
__func__);
for (i = 0; i < MAC_ADDRESS_SIZE; i++) {
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL,
"SRC MAC[%x] = %x ClassifierRuleSrcMAC = %x Mask : %x\n", i, Mac[i],
pstClassifierRule->au8EThCSSrcMAC[i], pstClassifierRule->au8EThCSSrcMACMask[i]);
if ((pstClassifierRule->au8EThCSSrcMAC[i] &
pstClassifierRule->au8EThCSSrcMACMask[i]) !=
@@ -607,7 +607,7 @@ static bool EthCSMatchDestMACAddress(struct
bcm_classifier_rule *pstClassifierRu
struct bcm_mini_adapter *Adapter = GET_BCM_ADAPTER(gblpnetdev);
if (pstClassifierRule->ucEthCSDestMACLen == 0)
return TRUE;
- BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, "%s\n",
__FUNCTION__);
+ BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, "%s\n",
__func__);
for (i = 0; i < MAC_ADDRESS_SIZE; i++) {
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL,
"SRC MAC[%x] = %x ClassifierRuleSrcMAC = %x Mask : %x\n", i, Mac[i],
pstClassifierRule->au8EThCSDestMAC[i],
pstClassifierRule->au8EThCSDestMACMask[i]);
if ((pstClassifierRule->au8EThCSDestMAC[i] &
pstClassifierRule->au8EThCSDestMACMask[i]) !=
@@ -624,9 +624,9 @@ static bool EthCSMatchEThTypeSAP(struct bcm_classifier_rule
*pstClassifierRule,
(pstClassifierRule->au8EthCSEtherType[0] == 0))
return TRUE;
- BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, "%s
SrcEtherType:%x CLS EtherType[0]:%x\n", __FUNCTION__,
pstEthCsPktInfo->usEtherType, pstClassifierRule->au8EthCSEtherType[0]);
+ BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, "%s
SrcEtherType:%x CLS EtherType[0]:%x\n", __func__, pstEthCsPktInfo->usEtherType,
pstClassifierRule->au8EthCSEtherType[0]);
if (pstClassifierRule->au8EthCSEtherType[0] == 1) {
- BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL,
"%s CLS EtherType[1]:%x EtherType[2]:%x\n", __FUNCTION__,
pstClassifierRule->au8EthCSEtherType[1],
pstClassifierRule->au8EthCSEtherType[2]);
+ BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL,
"%s CLS EtherType[1]:%x EtherType[2]:%x\n", __func__,
pstClassifierRule->au8EthCSEtherType[1],
pstClassifierRule->au8EthCSEtherType[2]);
if (memcmp(>usEtherType,
>au8EthCSEtherType[1], 2) == 0)
return TRUE;
@@ -638,7 +638,7 @@ static bool EthCSMatchEThTypeSAP(struct bcm_classifier_rule
*pstClassifierRule,
if (eEth802LLCFrame !=
Re: linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell
Date: Fri, 23 May 2014 13:46:02 +1000
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/bonding/bond_alb.c between commit d0c21d43a5a1 ("bonding:
> Send ALB learning packets using the right source") from the net tree
> and commit 8557cd74ca8a ("bonding: replace SLAVE_IS_OK() with
> bond_slave_can_tx()") from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Thanks Stephen, I just merged net into net-next and this conflict
should therefore be gone.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 41/49] media: davinci: vpif_capture: drop unneeded module params
Hi Mauro,
On Sat, May 24, 2014 at 4:08 AM, Mauro Carvalho Chehab
wrote:
> Em Fri, 16 May 2014 19:03:47 +0530
> "Lad, Prabhakar" escreveu:
>
>> From: "Lad, Prabhakar"
>>
>> Signed-off-by: Lad, Prabhakar
>
> -ENOPATCHDESCRIPTION
>
> Why to remove those parameters? Please _ALWAYS_ describe your patches.
>
My bad! will take care next time.
Thanks,
--Prabhakar Lad
> My crystal ball is malfunctioning today, so I was unable to scry the
> reasons for this patch.
>
> Thanks,
> Mauro
>
>> ---
>> drivers/media/platform/davinci/vpif_capture.c | 54
>> +
>> drivers/media/platform/davinci/vpif_capture.h | 11 -
>> 2 files changed, 1 insertion(+), 64 deletions(-)
>>
>> diff --git a/drivers/media/platform/davinci/vpif_capture.c
>> b/drivers/media/platform/davinci/vpif_capture.c
>> index d452eaf..e967cf7 100644
>> --- a/drivers/media/platform/davinci/vpif_capture.c
>> +++ b/drivers/media/platform/davinci/vpif_capture.c
>> @@ -38,32 +38,10 @@ MODULE_VERSION(VPIF_CAPTURE_VERSION);
>> v4l2_dbg(level, debug, _obj.v4l2_dev, fmt, ## arg)
>>
>> static int debug = 1;
>> -static u32 ch0_numbuffers = 3;
>> -static u32 ch1_numbuffers = 3;
>> -static u32 ch0_bufsize = 1920 * 1080 * 2;
>> -static u32 ch1_bufsize = 720 * 576 * 2;
>>
>> module_param(debug, int, 0644);
>> -module_param(ch0_numbuffers, uint, S_IRUGO);
>> -module_param(ch1_numbuffers, uint, S_IRUGO);
>> -module_param(ch0_bufsize, uint, S_IRUGO);
>> -module_param(ch1_bufsize, uint, S_IRUGO);
>>
>> MODULE_PARM_DESC(debug, "Debug level 0-1");
>> -MODULE_PARM_DESC(ch2_numbuffers, "Channel0 buffer count (default:3)");
>> -MODULE_PARM_DESC(ch3_numbuffers, "Channel1 buffer count (default:3)");
>> -MODULE_PARM_DESC(ch2_bufsize, "Channel0 buffer size (default:1920 x 1080 x
>> 2)");
>> -MODULE_PARM_DESC(ch3_bufsize, "Channel1 buffer size (default:720 x 576 x
>> 2)");
>> -
>> -static struct vpif_config_params config_params = {
>> - .min_numbuffers = 3,
>> - .numbuffers[0] = 3,
>> - .numbuffers[1] = 3,
>> - .min_bufsize[0] = 720 * 480 * 2,
>> - .min_bufsize[1] = 720 * 480 * 2,
>> - .channel_bufsize[0] = 1920 * 1080 * 2,
>> - .channel_bufsize[1] = 720 * 576 * 2,
>> -};
>>
>> #define VPIF_DRIVER_NAME "vpif_capture"
>>
>> @@ -609,9 +587,6 @@ static void vpif_config_format(struct channel_obj *ch)
>> vpif_dbg(2, debug, "vpif_config_format\n");
>>
>> common->fmt.fmt.pix.field = V4L2_FIELD_ANY;
>> - common->fmt.fmt.pix.sizeimage
>> - = config_params.channel_bufsize[ch->channel_id];
>> -
>> if (ch->vpifparams.iface.if_type == VPIF_IF_RAW_BAYER)
>> common->fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_SBGGR8;
>> else
>> @@ -1358,36 +1333,9 @@ static struct v4l2_file_operations vpif_fops = {
>> */
>> static int initialize_vpif(void)
>> {
>> - int err = 0, i, j;
>> + int err, i, j;
>> int free_channel_objects_index;
>>
>> - /* Default number of buffers should be 3 */
>> - if ((ch0_numbuffers > 0) &&
>> - (ch0_numbuffers < config_params.min_numbuffers))
>> - ch0_numbuffers = config_params.min_numbuffers;
>> - if ((ch1_numbuffers > 0) &&
>> - (ch1_numbuffers < config_params.min_numbuffers))
>> - ch1_numbuffers = config_params.min_numbuffers;
>> -
>> - /* Set buffer size to min buffers size if it is invalid */
>> - if (ch0_bufsize < config_params.min_bufsize[VPIF_CHANNEL0_VIDEO])
>> - ch0_bufsize =
>> - config_params.min_bufsize[VPIF_CHANNEL0_VIDEO];
>> - if (ch1_bufsize < config_params.min_bufsize[VPIF_CHANNEL1_VIDEO])
>> - ch1_bufsize =
>> - config_params.min_bufsize[VPIF_CHANNEL1_VIDEO];
>> -
>> - config_params.numbuffers[VPIF_CHANNEL0_VIDEO] = ch0_numbuffers;
>> - config_params.numbuffers[VPIF_CHANNEL1_VIDEO] = ch1_numbuffers;
>> - if (ch0_numbuffers) {
>> - config_params.channel_bufsize[VPIF_CHANNEL0_VIDEO]
>> - = ch0_bufsize;
>> - }
>> - if (ch1_numbuffers) {
>> - config_params.channel_bufsize[VPIF_CHANNEL1_VIDEO]
>> - = ch1_bufsize;
>> - }
>> -
>> /* Allocate memory for six channel objects */
>> for (i = 0; i < VPIF_CAPTURE_MAX_DEVICES; i++) {
>> vpif_obj.dev[i] =
>> diff --git a/drivers/media/platform/davinci/vpif_capture.h
>> b/drivers/media/platform/davinci/vpif_capture.h
>> index 4960504..537076a 100644
>> --- a/drivers/media/platform/davinci/vpif_capture.h
>> +++ b/drivers/media/platform/davinci/vpif_capture.h
>> @@ -125,16 +125,5 @@ struct vpif_device {
>> struct vpif_capture_config *config;
>> };
>>
>> -struct vpif_config_params {
>> - u8 min_numbuffers;
>> - u8 numbuffers[VPIF_CAPTURE_NUM_CHANNELS];
>> - s8 device_type;
>> - u32 min_bufsize[VPIF_CAPTURE_NUM_CHANNELS];
>> - u32 channel_bufsize[VPIF_CAPTURE_NUM_CHANNELS];
>> - u8 default_device[VPIF_CAPTURE_NUM_CHANNELS];
>> -
Re: [PATCH v2 2/2] of: Stop naming platform_device using dcr address
On Fri, 2014-05-23 at 08:36 +0900, Grant Likely wrote:
> There is now a way to ensure all platform devices get a unique name when
> populated from the device tree, and the DCR_NATIVE code path is broken
> anyway. PowerPC Cell (PS3) is the only platform that actually uses this
> path. Most likely nobody will notice if it is killed. Remove the code
> and associated ugly #ifdef.
>
> The user-visible impact of this patch is that any DCR device on Cell
> will get a new name in the /sys/devices hierarchy.
I don't understand. First DCR devices cover more than Cell (and not even
PS3). All 4xx embedded have some form of DCR based devices so I don't
know how much we use as "platform".
What do you mean by "the DCR_NATIVE" code path is broken anyway ?
Changing user visible platform device names has broken stuff in the
past, I'm not saying it is now but I'd like a better justification
for removing this.
Cheers,
Ben.
> Signed-off-by: Grant Likely
> Cc: Rob Herring
> Cc: Benjamin Herrenschmidt
> ---
> arch/powerpc/include/asm/dcr-mmio.h | 4
> arch/powerpc/sysdev/dcr.c | 6 +++---
> drivers/of/platform.c | 24
> 3 files changed, 3 insertions(+), 31 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/dcr-mmio.h
> b/arch/powerpc/include/asm/dcr-mmio.h
> index acd491dbd45a..93a68b28e695 100644
> --- a/arch/powerpc/include/asm/dcr-mmio.h
> +++ b/arch/powerpc/include/asm/dcr-mmio.h
> @@ -51,10 +51,6 @@ static inline void dcr_write_mmio(dcr_host_mmio_t host,
> out_be32(host.token + ((host.base + dcr_n) * host.stride), value);
> }
>
> -extern u64 of_translate_dcr_address(struct device_node *dev,
> - unsigned int dcr_n,
> - unsigned int *stride);
> -
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_DCR_MMIO_H */
>
> diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c
> index 1bd0eba4d355..e9056e438575 100644
> --- a/arch/powerpc/sysdev/dcr.c
> +++ b/arch/powerpc/sysdev/dcr.c
> @@ -152,9 +152,9 @@ EXPORT_SYMBOL_GPL(dcr_resource_len);
>
> #ifdef CONFIG_PPC_DCR_MMIO
>
> -u64 of_translate_dcr_address(struct device_node *dev,
> - unsigned int dcr_n,
> - unsigned int *out_stride)
> +static u64 of_translate_dcr_address(struct device_node *dev,
> + unsigned int dcr_n,
> + unsigned int *out_stride)
> {
> struct device_node *dp;
> const u32 *p;
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 95c133a0554b..52780a72d09d 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -51,10 +51,6 @@ struct platform_device *of_find_device_by_node(struct
> device_node *np)
> }
> EXPORT_SYMBOL(of_find_device_by_node);
>
> -#if defined(CONFIG_PPC_DCR)
> -#include
> -#endif
> -
> #ifdef CONFIG_OF_ADDRESS
> /*
> * The following routines scan a subtree and registers a device for
> @@ -78,26 +74,6 @@ void of_device_make_bus_id(struct device *dev)
> const __be32 *reg;
> u64 addr;
>
> -#ifdef CONFIG_PPC_DCR
> - /*
> - * If it's a DCR based device, use 'd' for native DCRs
> - * and 'D' for MMIO DCRs.
> - */
> - reg = of_get_property(node, "dcr-reg", NULL);
> - if (reg) {
> -#ifdef CONFIG_PPC_DCR_NATIVE
> - dev_set_name(dev, "d%x.%s", *reg, node->name);
> -#else /* CONFIG_PPC_DCR_NATIVE */
> - u64 addr = of_translate_dcr_address(node, *reg, NULL);
> - if (addr != OF_BAD_ADDR) {
> - dev_set_name(dev, "D%llx.%s",
> - (unsigned long long)addr, node->name);
> - return;
> - }
> -#endif /* !CONFIG_PPC_DCR_NATIVE */
> - }
> -#endif /* CONFIG_PPC_DCR */
> -
> /* Construct the name, using parent nodes if necessary to ensure
> uniqueness */
> while (node->parent) {
> /*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 00/49] DaVinci: vpif: upgrade with v4l helpers and v4l compliance fixes
Hi Hans, Thanks for the review from 2 patches to 50 :) On Fri, May 23, 2014 at 2:00 PM, Hans Verkuil wrote: > Hi Prabhakar, > > Thanks for this patch series, it looks good to me and I'll make a pull > request for this. > Thanks. > I did find a few issues, but they are all pre-existing problems, so they > can be fixed in follow-up patches. > > I'll comment on those in the relevant patches. Since display and capture are > so similar I will only comment on the display patches, but it's valid for > both. > Ok will fix them up soon I am relocating next week so will take me at-least 2-3 weeks for me to get back the boards and get in action. Regards, --Prabhakar Lad > Regards, > > Hans > > On 05/16/2014 03:33 PM, Lad, Prabhakar wrote: >> From: "Lad, Prabhakar" >> >> Hi, >> >> This patch series upgrades the vpif capture & display >> driver with the all the helpers provided by v4l, this makes >> the driver much simpler and cleaner. This also includes few >> checkpatch issues. >> >> Changes for v2: >> a> Added a copyright. >> b> Dropped buf_init() callback from vb2_ops. >> c> Fixed enabling & disabling of interrupts in case of HD formats. >> >> Changes for v3: >> a> Fixed review comments pointed by Hans. >> >> Changes for v4: Rebased the patches on media tree. >> >> Changes for v5: Split up the patches >> >> Following is the output of v4l-compliance for capture: >> -- >> >> ./v4l2-compliance -d /dev/video0 -i 0 -s -v --expbuf-device=2 >> >> Driver Info: >> Driver name : vpif_capture >> Card type : DA850/OMAP-L138 Video Capture >> Bus info : platform:vpif_capture >> Driver version: 3.15.0 >> Capabilities : 0x8401 >> Video Capture >> Streaming >> Device Capabilities >> Device Caps : 0x0401 >> Video Capture >> Streaming >> >> Compliance test for device /dev/video0 (not using libv4l2): >> >> Required ioctls: >> test VIDIOC_QUERYCAP: OK >> >> Allow for multiple opens: >> test second video open: OK >> test VIDIOC_QUERYCAP: OK >> test VIDIOC_G/S_PRIORITY: OK >> >> Debug ioctls: >> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) >> test VIDIOC_LOG_STATUS: OK >> >> Input ioctls: >> test VIDIOC_G/S_TUNER: OK (Not Supported) >> test VIDIOC_G/S_FREQUENCY: OK (Not Supported) >> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) >> test VIDIOC_ENUMAUDIO: OK (Not Supported) >> test VIDIOC_G/S/ENUMINPUT: OK >> test VIDIOC_G/S_AUDIO: OK (Not Supported) >> Inputs: 1 Audio Inputs: 0 Tuners: 0 >> >> Output ioctls: >> test VIDIOC_G/S_MODULATOR: OK (Not Supported) >> test VIDIOC_G/S_FREQUENCY: OK (Not Supported) >> test VIDIOC_ENUMAUDOUT: OK (Not Supported) >> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) >> test VIDIOC_G/S_AUDOUT: OK (Not Supported) >> Outputs: 0 Audio Outputs: 0 Modulators: 0 >> >> Input/Output configuration ioctls: >> test VIDIOC_ENUM/G/S/QUERY_STD: OK >> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) >> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) >> test VIDIOC_G/S_EDID: OK (Not Supported) >> >> Test input 0: >> >> Control ioctls: >> test VIDIOC_QUERYCTRL/MENU: OK (Not Supported) >> test VIDIOC_G/S_CTRL: OK (Not Supported) >> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) >> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) >> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) >> Standard Controls: 0 Private Controls: 0 >> >> Format ioctls: >> info: found 1 formats for buftype 1 >> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK >> fail: v4l2-test-formats.cpp(1003): cap->readbuffers >> test VIDIOC_G/S_PARM: FAIL >> test VIDIOC_G_FBUF: OK (Not Supported) >> test VIDIOC_G_FMT: OK >> test VIDIOC_TRY_FMT: OK >> test VIDIOC_S_FMT: OK >> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) >> >> Codec ioctls: >> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) >> test VIDIOC_G_ENC_INDEX: OK (Not Supported) >> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) >> >> Buffer ioctls: >> info: test buftype Video Capture >> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK >> test VIDIOC_EXPBUF: OK >> test read/write: OK (Not Supported) >> Video Capture: >> Buffer: 0 Sequence: 0 Field: Interlaced Timestamp: >> 145.509130s >> Buffer: 1 Sequence: 0 Field: Interlaced Timestamp: >> 145.549125s >> Buffer: 2 Sequence: 0
[PATCH RESEND] staging: slicoss: remove private netdev list
Remove the private linked list of netdev structs. This list isn't
being used anyway.
This patch has no noticable effect.
Signed-off-by: David Matlack
---
drivers/staging/slicoss/slic.h| 1 -
drivers/staging/slicoss/slicoss.c | 4
2 files changed, 5 deletions(-)
diff --git a/drivers/staging/slicoss/slic.h b/drivers/staging/slicoss/slic.h
index 7de57c4..0dc73d5 100644
--- a/drivers/staging/slicoss/slic.h
+++ b/drivers/staging/slicoss/slic.h
@@ -407,7 +407,6 @@ struct adapter {
uintcard_size;
uintchipid;
struct net_device *netdev;
- struct net_device *next_netdevice;
struct slic_spinlock adapter_lock;
struct slic_spinlock reset_lock;
struct pci_dev *pcidev;
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index b8eeb3b..0165899 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -104,8 +104,6 @@ static char *slic_banner = "Alacritech SLIC Technology(tm)
Server "
static char *slic_proc_version = "2.0.351 2006/07/14 12:26:00";
-static struct net_device *head_netdevice;
-
static struct base_driver slic_global = { {}, 0, 0, 0, 1, NULL, NULL };
static int intagg_delay = 100;
static u32 dynamic_intagg;
@@ -2993,8 +2991,6 @@ static void slic_init_adapter(struct net_device *netdev,
adapter->slic_regs = (__iomem struct slic_regs *)memaddr;
adapter->irq = pcidev->irq;
/* adapter->netdev = netdev;*/
- adapter->next_netdevice = head_netdevice;
- head_netdevice = netdev;
adapter->chipid = chip_idx;
adapter->port = 0; /*adapter->functionnumber;*/
adapter->cardindex = adapter->port;
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] staging: slicoss: clean up use of dev_err
First, don't print pci device information or driver prefixes, this
is already printed by dev_err. Next, don't report error messages
via dev_err when the failing function already reports all errors
via dev_err.
Signed-off-by: David Matlack
---
drivers/staging/slicoss/slicoss.c | 28 +---
1 file changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index 0165899..1278de8 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -395,7 +395,7 @@ static int slic_card_download_gbrcv(struct adapter *adapter)
ret = request_firmware(, file, >pcidev->dev);
if (ret) {
dev_err(>pcidev->dev,
- "SLICOSS: Failed to load firmware %s\n", file);
+ "Failed to load firmware %s\n", file);
return ret;
}
@@ -473,7 +473,7 @@ static int slic_card_download(struct adapter *adapter)
ret = request_firmware(, file, >pcidev->dev);
if (ret) {
dev_err(>pcidev->dev,
- "SLICOSS: Failed to load firmware %s\n", file);
+ "Failed to load firmware %s\n", file);
return ret;
}
numsects = *(u32 *)(fw->data + index);
@@ -2783,13 +2783,8 @@ static int slic_card_init(struct sliccard *card, struct
adapter *adapter)
/* Download the microcode */
status = slic_card_download(adapter);
-
- if (status != 0) {
- dev_err(>pcidev->dev,
- "download failed bus %d slot %d\n",
- adapter->busnumber, adapter->slotnumber);
+ if (status)
return status;
- }
if (!card->config_set) {
peeprom = pci_alloc_consistent(adapter->pcidev,
@@ -2801,8 +2796,7 @@ static int slic_card_init(struct sliccard *card, struct
adapter *adapter)
if (!peeprom) {
dev_err(>pcidev->dev,
- "eeprom read failed to get memory bus %d slot
%d\n", adapter->busnumber,
- adapter->slotnumber);
+ "Failed to allocate DMA memory for EEPROM.\n");
return -ENOMEM;
} else {
memset(peeprom, 0, sizeof(struct slic_eeprom));
@@ -2846,8 +2840,7 @@ static int slic_card_init(struct sliccard *card, struct
adapter *adapter)
i++;
if (i > 5000) {
dev_err(>pcidev->dev,
- "%d config data fetch timed
out!\n",
- adapter->port);
+ "Fetch of config data timed
out.\n");
slic_reg64_write(adapter,
_regs->slic_isp, 0,
_regs->slic_addr_upper,
@@ -2931,19 +2924,16 @@ static int slic_card_init(struct sliccard *card, struct
adapter *adapter)
slic_reg64_write(adapter, _regs->slic_isp, 0,
_regs->slic_addr_upper,
0, FLUSH);
- dev_err(>pcidev->dev,
- "unsupported CONFIGURATION EEPROM invalid\n");
+ dev_err(>pcidev->dev, "EEPROM invalid.\n");
return -EINVAL;
}
card->config_set = 1;
}
- if (slic_card_download_gbrcv(adapter)) {
- dev_err(>pcidev->dev,
- "unable to download GB receive microcode\n");
- return -EINVAL;
- }
+ status = slic_card_download_gbrcv(adapter);
+ if (status)
+ return status;
if (slic_global.dynamic_intagg)
slic_intagg_set(adapter, 0);
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 04/49] media: davinci: vpif_display: release buffers in case start_streaming() call back fails
Hi Hans,
Thanks for the review.
On Fri, May 23, 2014 at 2:05 PM, Hans Verkuil wrote:
> On 05/16/2014 03:33 PM, Lad, Prabhakar wrote:
>> From: "Lad, Prabhakar"
>>
>> this patch adds support to release the buffer by calling
>> vb2_buffer_done(), with state marked as VB2_BUF_STATE_QUEUED
>> if start_streaming() call back fails.
>>
>> Signed-off-by: Lad, Prabhakar
>> ---
>> drivers/media/platform/davinci/vpif_display.c | 42
>> +++--
>> 1 file changed, 26 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/media/platform/davinci/vpif_display.c
>> b/drivers/media/platform/davinci/vpif_display.c
>> index 8bb9f02..1a17a45 100644
>> --- a/drivers/media/platform/davinci/vpif_display.c
>> +++ b/drivers/media/platform/davinci/vpif_display.c
>> @@ -196,26 +196,16 @@ static int vpif_start_streaming(struct vb2_queue *vq,
>> unsigned int count)
>> struct channel_obj *ch = vb2_get_drv_priv(vq);
>> struct common_obj *common = >common[VPIF_VIDEO_INDEX];
>> struct vpif_params *vpif = >vpifparams;
>> - unsigned long addr = 0;
>> - unsigned long flags;
>> + struct vpif_disp_buffer *buf, *tmp;
>> + unsigned long addr, flags;
>> int ret;
>>
>> spin_lock_irqsave(>irqlock, flags);
>>
>> - /* Get the next frame from the buffer queue */
>> - common->next_frm = common->cur_frm =
>> - list_entry(common->dma_queue.next,
>> -struct vpif_disp_buffer, list);
>> -
>> - list_del(>cur_frm->list);
>> - spin_unlock_irqrestore(>irqlock, flags);
>> - /* Mark state of the current frame to active */
>> - common->cur_frm->vb.state = VB2_BUF_STATE_ACTIVE;
>> -
>> /* Initialize field_id and started member */
>> ch->field_id = 0;
>> common->started = 1;
>> - addr = vb2_dma_contig_plane_dma_addr(>cur_frm->vb, 0);
>> +
>> /* Calculate the offset for Y and C data in the buffer */
>> vpif_calculate_offsets(ch);
>>
>> @@ -225,7 +215,8 @@ static int vpif_start_streaming(struct vb2_queue *vq,
>> unsigned int count)
>> || (!ch->vpifparams.std_info.frm_fmt
>> && (common->fmt.fmt.pix.field == V4L2_FIELD_NONE))) {
>> vpif_err("conflict in field format and std format\n");
>> - return -EINVAL;
>> + ret = -EINVAL;
>> + goto err;
>> }
>>
>> /* clock settings */
>> @@ -234,17 +225,28 @@ static int vpif_start_streaming(struct vb2_queue *vq,
>> unsigned int count)
>> ycmux_mode, ch->vpifparams.std_info.hd_sd);
>> if (ret < 0) {
>> vpif_err("can't set clock\n");
>> - return ret;
>> + goto err;
>> }
>> }
>>
>> /* set the parameters and addresses */
>> ret = vpif_set_video_params(vpif, ch->channel_id + 2);
>> if (ret < 0)
>> - return ret;
>> + goto err;
>>
>> common->started = ret;
>> vpif_config_addr(ch, ret);
>> + /* Get the next frame from the buffer queue */
>> + common->next_frm = common->cur_frm =
>> + list_entry(common->dma_queue.next,
>> +struct vpif_disp_buffer, list);
>> +
>> + list_del(>cur_frm->list);
>> + spin_unlock_irqrestore(>irqlock, flags);
>> + /* Mark state of the current frame to active */
>> + common->cur_frm->vb.state = VB2_BUF_STATE_ACTIVE;
>
> There is no need to set this, all buffers queued to the driver are always in
> state
> ACTIVE. The vb2 core sets that for you. In general drivers never need to
> change the
> state manually.
>
> It happens twice in this driver and in both cases the assignment can be
> removed.
>
OK, will drop this.
Regards,
--Prabhakar Lad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 2/4] bridge: adhere to querier election mechanism specified by RFCs
From: Linus Lüssing Date: Wed, 21 May 2014 10:59:00 +0200 > + if (saddr <= br->ip4_querier.addr.u.ip4) > + goto update; It is clear to me that you should be making these comparisons in cpu endianness. Otherwise the code will handle the same situations differently on big-endian vs. little-endian machines. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: core: Use map_voltage_linear_range by default for list_voltage_linear_range
Use map_voltage_linear_range() if list_voltage_linear_range() is in use and nothing is set. Signed-off-by: Axel Lin --- drivers/regulator/core.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index b97ffd2..7399cbf 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -2321,6 +2321,10 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev, regulator_list_voltage_linear) ret = regulator_map_voltage_linear(rdev, min_uV, max_uV); + else if (rdev->desc->ops->list_voltage == +regulator_list_voltage_linear_range) + ret = regulator_map_voltage_linear_range(rdev, + min_uV, max_uV); else ret = regulator_map_voltage_iterate(rdev, min_uV, max_uV); -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: lustre: Fixed warnings about using 0 as NULL ptr
Fixed a bunch of warnings pointed out by sparse about using 0 to
represent a NULL pointer.
Signed-off-by: Greg DeAngelis
---
drivers/staging/lustre/lustre/mgc/lproc_mgc.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/lustre/lustre/mgc/lproc_mgc.c
b/drivers/staging/lustre/lustre/mgc/lproc_mgc.c
index 1506af1..6c877c5 100644
--- a/drivers/staging/lustre/lustre/mgc/lproc_mgc.c
+++ b/drivers/staging/lustre/lustre/mgc/lproc_mgc.c
@@ -56,21 +56,21 @@ static int mgc_ir_state_seq_show(struct seq_file *m, void
*v)
LPROC_SEQ_FOPS_RO(mgc_ir_state);
static struct lprocfs_vars lprocfs_mgc_obd_vars[] = {
- { "uuid",_uuid_fops, 0, 0 },
- { "ping",_ping_fops, 0, 0222 },
- { "connect_flags", _connect_flags_fops, 0, 0 },
- { "mgs_server_uuid", _server_uuid_fops, 0, 0 },
- { "mgs_conn_uuid", _conn_uuid_fops, 0, 0 },
- { "import", _import_fops, 0, 0 },
- { "state", _state_fops,0, 0 },
- { "ir_state",_ir_state_fops, 0, 0 },
- { 0 }
+ { "uuid",_uuid_fops, NULL, 0 },
+ { "ping",_ping_fops, NULL, 0222 },
+ { "connect_flags", _connect_flags_fops, NULL, 0 },
+ { "mgs_server_uuid", _server_uuid_fops, NULL, 0 },
+ { "mgs_conn_uuid", _conn_uuid_fops, NULL, 0 },
+ { "import", _import_fops, NULL, 0 },
+ { "state", _state_fops,NULL, 0 },
+ { "ir_state",_ir_state_fops, NULL, 0 },
+ { NULL }
};
LPROC_SEQ_FOPS_RO_TYPE(mgc, numrefs);
static struct lprocfs_vars lprocfs_mgc_module_vars[] = {
- { "num_refs", _numrefs_fops, 0, 0 },
- { 0 }
+ { "num_refs", _numrefs_fops, NULL, 0 },
+ { NULL }
};
void lprocfs_mgc_init_vars(struct lprocfs_static_vars *lvars)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[V1 PATCH] dom0 pvh linux support
Hi, Attached please find patch for linux to support toolstack on pvh dom0. thanks, Mukesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[V1 PATCH] dom0 pvh: map foreign pfns in our p2m for toolstack
When running as dom0 in pvh mode, foreign pfns that are accessed must be
added to our p2m which is managed by xen. This is done via
XENMEM_add_to_physmap_range hypercall. This is needed for toolstack
building guests and mapping guest memory, xentrace mapping xen pages,
etc..
Signed-off-by: Mukesh Rathor
---
arch/x86/xen/mmu.c | 115 +++--
1 file changed, 112 insertions(+), 3 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 86e02ea..8efc066 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2510,6 +2510,93 @@ void __init xen_hvm_init_mmu_ops(void)
}
#endif
+#ifdef CONFIG_XEN_PVH
+/*
+ * Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space
+ * creating new guest on pvh dom0 and needing to map domU pages.
+ */
+static int xlate_add_to_p2m(unsigned long lpfn, unsigned long fgmfn,
+ unsigned int domid)
+{
+ int rc, err = 0;
+ xen_pfn_t gpfn = lpfn;
+ xen_ulong_t idx = fgmfn;
+
+ struct xen_add_to_physmap_range xatp = {
+ .domid = DOMID_SELF,
+ .foreign_domid = domid,
+ .size = 1,
+ .space = XENMAPSPACE_gmfn_foreign,
+ };
+ set_xen_guest_handle(xatp.idxs, );
+ set_xen_guest_handle(xatp.gpfns, );
+ set_xen_guest_handle(xatp.errs, );
+
+ rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, );
+ return rc;
+}
+
+static int xlate_remove_from_p2m(unsigned long spfn, int count)
+{
+ struct xen_remove_from_physmap xrp;
+ int i, rc;
+
+ for (i = 0; i < count; i++) {
+ xrp.domid = DOMID_SELF;
+ xrp.gpfn = spfn+i;
+ rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, );
+ if (rc)
+ break;
+ }
+ return rc;
+}
+
+struct xlate_remap_data {
+ unsigned long fgmfn; /* foreign domain's gmfn */
+ pgprot_t prot;
+ domid_t domid;
+ int index;
+ struct page **pages;
+};
+
+static int xlate_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
+ void *data)
+{
+ int rc;
+ struct xlate_remap_data *remap = data;
+ unsigned long pfn = page_to_pfn(remap->pages[remap->index++]);
+ pte_t pteval = pte_mkspecial(pfn_pte(pfn, remap->prot));
+
+ rc = xlate_add_to_p2m(pfn, remap->fgmfn, remap->domid);
+ if (rc)
+ return rc;
+ native_set_pte(ptep, pteval);
+
+ return 0;
+}
+
+static int xlate_remap_gmfn_range(struct vm_area_struct *vma,
+ unsigned long addr, unsigned long mfn,
+ int nr, pgprot_t prot, unsigned domid,
+ struct page **pages)
+{
+ int err;
+ struct xlate_remap_data pvhdata;
+
+ BUG_ON(!pages);
+
+ pvhdata.fgmfn = mfn;
+ pvhdata.prot = prot;
+ pvhdata.domid = domid;
+ pvhdata.index = 0;
+ pvhdata.pages = pages;
+ err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
+ xlate_map_pte_fn, );
+ flush_tlb_all();
+ return err;
+}
+#endif
+
#define REMAP_BATCH_SIZE 16
struct remap_data {
@@ -2544,13 +2631,20 @@ int xen_remap_domain_mfn_range(struct vm_area_struct
*vma,
unsigned long range;
int err = 0;
- if (xen_feature(XENFEAT_auto_translated_physmap))
- return -EINVAL;
-
prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP);
BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
+ if (xen_feature(XENFEAT_auto_translated_physmap)) {
+#ifdef CONFIG_XEN_PVH
+ /* We need to update the local page tables and the xen HAP */
+ return xlate_remap_gmfn_range(vma, addr, mfn, nr, prot,
+ domid, pages);
+#else
+ return -EINVAL;
+#endif
+ }
+
rmd.mfn = mfn;
rmd.prot = prot;
@@ -2588,6 +2682,21 @@ int xen_unmap_domain_mfn_range(struct vm_area_struct
*vma,
if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
return 0;
+#ifdef CONFIG_XEN_PVH
+ while (numpgs--) {
+
+ /* The mmu has already cleaned up the process mmu resources at
+* this point (lookup_address will return NULL). */
+ unsigned long pfn = page_to_pfn(pages[numpgs]);
+
+ xlate_remove_from_p2m(pfn, 1);
+ }
+ /* We don't need to flush tlbs because as part of xlate_remove_from_p2m,
+* the hypervisor will do tlb flushes after removing the p2m entries
+* from the EPT/NPT */
+ return 0;
+#else
return -EINVAL;
+#endif
}
EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
[PATCH] x86/mce: Fix incorrect comment in do_machine_check()
In do_machine_check function, we can find the following code segment: * ... */* mce_clear_state will clear *final, save locally for use later */ *m = *final; * *if (!no_way_out) *mce_clear_state(toclear); * ... But the reality is that mce_clear_state function will not clear *final. It is just used to clear bank MSRs or the relative field of injectm used by MCE-Injection. Meanwhile, mce_reign executed by monarch CPU will clear *final, therefore we need to save it locally for use later. Signed-off-by: Chen Yucong --- arch/x86/kernel/cpu/mcheck/mce.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c index 68317c8..83159c1 100644 --- a/arch/x86/kernel/cpu/mcheck/mce.c +++ b/arch/x86/kernel/cpu/mcheck/mce.c @@ -1137,7 +1137,9 @@ void do_machine_check(struct pt_regs *regs, long error_code) } } - /* mce_clear_state will clear *final, save locally for use later */ + /* mce_reign executed by monarch CPU will clear *final(mces_seen), +* save locally for use later +*/ m = *final; if (!no_way_out) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net] bridge: notify user space of fdb port change
> I have no more comments except for style problems (bracket position,
> indentation, type mismatch).
> thank you for rewriting :)
np, yes this is a draft but I will make sure complies with checkpatch.pl
before submitting it.
Regards
Jon
>
> Thanks,
> Toshiaki Makita
>
> >
> > $ diff -Naur br_fdb.c br_fdb.c.patch
> > --- br_fdb.c2014-05-17 12:43:23.346319609 +1000
> > +++ br_fdb.c.patch2014-05-17 16:54:46.280235728 +1000
> > @@ -487,6 +487,7 @@
> > {
> > struct hlist_head *head = >hash[br_mac_hash(addr, vid)];
> > struct net_bridge_fdb_entry *fdb;
> > +bool fdb_modified = 0;
> >
> > /* some users want to always flood. */
> > if (hold_time(br) == 0)
> > @@ -507,10 +508,16 @@
> > source->dev->name);
> > } else {
> > /* fastpath: update of existing entry */
> > -fdb->dst = source;
> > +if (unlikely(source != fdb->dst))
> > +{
> > +fdb->dst = source;
> > +fdb_modified = 1;
> > +}
> > fdb->updated = jiffies;
> > if (unlikely(added_by_user))
> > fdb->added_by_user = 1;
> > +if (unlikely(fdb_modified))
> > +fdb_notify(br, fdb, RTM_NEWNEIGH);
> > }
> > } else {
> > spin_lock(>hash_lock);
> >
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/3] CMA: aggressively allocate the pages on cma reserved memory when not used
On 5/12/2014 10:04 AM, Laura Abbott wrote: > > I'm going to see about running this through tests internally for comparison. > Hopefully I'll get useful results in a day or so. > > Thanks, > Laura > We ran some tests internally and found that for our purposes these patches made the benchmarks worse vs. the existing implementation of using CMA first for some pages. These are mostly androidisms but androidisms that we care about for having a device be useful. The foreground memory headroom on the device was on average about 40 MB smaller when using these patches vs our existing implementation of something like solution #1. By foreground memory headroom we simply mean the amount of memory that the foreground application can allocate before it is killed by the Android Low Memory killer. We also found that when running a sequence of app launches these patches had more high priority app kills by the LMK and more alloc stalls. The test did a total of 500 hundred app launches (using 9 separate applications) The CMA memory in our system is rarely used by its client and is therefore available to the system most of the time. Test device - 4 CPUs - Android 4.4.2 - 512MB of RAM - 68 MB of CMA Results: Existing solution: Foreground headroom: 200MB Number of higher priority LMK kills (oom_score_adj < 529): 332 Number of alloc stalls: 607 Test patches: Foreground headroom: 160MB Number of higher priority LMK kills (oom_score_adj < 529): 459 Number of alloc stalls: 29538 We believe that the issues seen with these patches are the result of the LMK being more aggressive. The LMK will be more aggressive because it will ignore free CMA pages for unmovable allocations, and since most calls to the LMK are made by kswapd (which uses GFP_KERNEL) the LMK will mostly ignore free CMA pages. Because the LMK thresholds are higher than the zone watermarks, there will often be a lot of free CMA pages in the system when the LMK is called, which the LMK will usually ignore. Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] spi: Set cs-gpios to output direction
Some gpios used for cs-gpios may not be configured for output by
default. In these cases gpio_set_value() won't have any effect
and so the chip select line won't toggle. Request the cs-gpios
and set them to output direction once we know if the chip select
is default high or default low.
Cc: Linus Walleij
Cc: Alexandre Courbot
Cc: Jean-Christophe PLAGNIOL-VILLARD
Cc: Richard Genoud
Signed-off-by: Stephen Boyd
---
I wonder if we should request the gpios when the master controller
probes or when a spi device is added? We only know what the default
value should be when the spi device is added. On the other hand,
we should probably fail probe if the gpio controller isn't ready when
the spi master controller probes.
Also, is it better to convert this over to the gpiod interfaces?
drivers/spi/spi.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 074f55f5d5ec..00f6365b3f87 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -431,8 +431,10 @@ int spi_add_device(struct spi_device *spi)
goto done;
}
- if (master->cs_gpios)
+ if (master->cs_gpios) {
spi->cs_gpio = master->cs_gpios[spi->chip_select];
+ gpio_direction_output(spi->cs_gpio, !(spi->mode & SPI_CS_HIGH));
+ }
/* Drivers may modify this initial i/o setup, but will
* normally rely on the device being setup. Devices
@@ -1512,8 +1514,11 @@ static int of_spi_register_master(struct spi_master
*master)
for (i = 0; i < master->num_chipselect; i++)
cs[i] = -ENOENT;
- for (i = 0; i < nb; i++)
+ for (i = 0; i < nb; i++) {
cs[i] = of_get_named_gpio(np, "cs-gpios", i);
+ devm_gpio_request(>dev, cs[i], "spi-cs");
+ }
+
return 0;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: bcm/kona: implement determine_rate()
Quoting Alex Elder (2014-05-23 16:24:31)
> On 05/23/2014 06:18 PM, Mike Turquette wrote:
> > Quoting Alex Elder (2014-05-20 06:24:57)
> >> Implement the clk->determine_rate method for Broadcom Kona peripheral
> >> clocks. This allows a peripheral clock to be re-parented in order to
> >> satisfy a rate change request. This takes the place of the previous
> >> kona_peri_clk_round_rate() functionality, though that function remains
> >> because it is used by the new one.
> >>
> >> The parent clock that allows the peripheral clock to produce a rate
> >> closest to the one requested is the one selected, though the current
> >> parent is used by default.
> >>
> >> Signed-off-by: Alex Elder
> >> ---
> >> This patch is based on Mike Turquette's current "clk-next" branch.
> >> 6ed8eb5 Merge tag 'clk-hisi-for-v3.16' of https://git.kern...
> >>
> >> It is available here:
> >> http://git.linaro.org/landing-teams/working/broadcom/kernel.git
> >> Branch review/bcm-determine-rate
> >>
> >> drivers/clk/bcm/clk-kona.c | 53
> >> +-
> >> 1 file changed, 52 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/clk/bcm/clk-kona.c b/drivers/clk/bcm/clk-kona.c
> >> index d603c4e..1a4eccc 100644
> >> --- a/drivers/clk/bcm/clk-kona.c
> >> +++ b/drivers/clk/bcm/clk-kona.c
> >> @@ -1031,6 +1031,57 @@ static long kona_peri_clk_round_rate(struct clk_hw
> >> *hw, unsigned long rate,
> >> rate ? rate : 1, *parent_rate, NULL);
> >> }
> >>
> >> +static long kona_peri_clk_determine_rate(struct clk_hw *hw, unsigned long
> >> rate,
> >> + unsigned long *best_parent_rate, struct clk **best_parent)
> >> +{
> >> + struct kona_clk *bcm_clk = to_kona_clk(hw);
> >> + struct clk *clk = hw->clk;
> >> + struct clk *current_parent;
> >> + unsigned long parent_rate;
> >> + unsigned long best_delta;
> >> + unsigned long best_rate;
> >> + u32 parent_count;
> >> + u32 which;
> >> +
> >> + /*
> >> +* If there is no other parent to choose, use the current one.
> >> +* Note: We don't honor (or use) CLK_SET_RATE_NO_REPARENT.
> >> +*/
> >
> > A WARN_ONCE is appropriate upon detection of CLK_SET_RATE_NO_REPARENT.
> > It will certainly help someone that is debugging why that flag has no
> > effect.
>
> I'll add that.
Thanks!
>
> > Otherwise the patch looks good to me.
>
> Would you like me to send an updated patch as a pull request?
It's up to you. For a single patch I can easily pick it. If you want to
bundle it up with the other pending patches (prereq clocks, etc) then a
pull request would be nice once all that stuff gets sorted.
Regards,
Mike
>
> Thanks.
>
> -Alex
>
> > Regards,
> > Mike
> >
> >> + parent_count = (u32)bcm_clk->init_data.num_parents;
> >> + if (parent_count < 2)
> >> + return kona_peri_clk_round_rate(hw, rate,
> >> best_parent_rate);
> >> +
> >> + /* Unless we can do better, stick with current parent */
> >> + current_parent = clk_get_parent(clk);
> >> + parent_rate = __clk_get_rate(current_parent);
> >> + best_rate = kona_peri_clk_round_rate(hw, rate, _rate);
> >> + best_delta = abs(best_rate - rate);
> >> +
> >> + /* Check whether any other parent clock can produce a better
> >> result */
> >> + for (which = 0; which < parent_count; which++) {
> >> + struct clk *parent = clk_get_parent_by_index(clk, which);
> >> + unsigned long delta;
> >> + unsigned long other_rate;
> >> +
> >> + BUG_ON(!parent);
> >> + if (parent == current_parent)
> >> + continue;
> >> +
> >> + /* We don't support CLK_SET_RATE_PARENT */
> >> + parent_rate = __clk_get_rate(parent);
> >> + other_rate = kona_peri_clk_round_rate(hw, rate,
> >> _rate);
> >> + delta = abs(other_rate - rate);
> >> + if (delta < best_delta) {
> >> + best_delta = delta;
> >> + best_rate = other_rate;
> >> + *best_parent = parent;
> >> + *best_parent_rate = parent_rate;
> >> + }
> >> + }
> >> +
> >> + return best_rate;
> >> +}
> >> +
> >> static int kona_peri_clk_set_parent(struct clk_hw *hw, u8 index)
> >> {
> >> struct kona_clk *bcm_clk = to_kona_clk(hw);
> >> @@ -1135,7 +1186,7 @@ struct clk_ops kona_peri_clk_ops = {
> >> .disable = kona_peri_clk_disable,
> >> .is_enabled = kona_peri_clk_is_enabled,
> >> .recalc_rate = kona_peri_clk_recalc_rate,
> >> - .round_rate = kona_peri_clk_round_rate,
> >> + .determine_rate = kona_peri_clk_determine_rate,
> >> .set_parent = kona_peri_clk_set_parent,
> >> .get_parent = kona_peri_clk_get_parent,
> >>
Re: [PATCH v2 2/5] clk: bcm281xx: implement prerequisite clocks
Quoting Alex Elder (2014-05-20 05:52:39)
> @@ -743,11 +746,16 @@ struct clk *kona_clk_setup(struct kona_clk *bcm_clk)
> clk = clk_register(NULL, _clk->hw);
> if (IS_ERR(clk)) {
> pr_err("%s: error registering clock %s (%ld)\n", __func__,
> - init_data->name, PTR_ERR(clk));
> + name, PTR_ERR(clk));
> goto out_teardown;
> }
> BUG_ON(!clk);
>
> + /* Make it so we can look the clock up using clk_find() */
s/clk_find/clk_get/ ?
> + bcm_clk->cl.con_id = name;
> + bcm_clk->cl.clk = clk;
> + clkdev_add(_clk->cl);
This is not so nice. I'll explain more below.
> +
> return clk;
> out_teardown:
> bcm_clk_teardown(bcm_clk);
> diff --git a/drivers/clk/bcm/clk-kona.c b/drivers/clk/bcm/clk-kona.c
> index d8a7f38..fd070d6 100644
> --- a/drivers/clk/bcm/clk-kona.c
> +++ b/drivers/clk/bcm/clk-kona.c
> @@ -1195,6 +1195,48 @@ static bool __peri_clk_init(struct kona_clk *bcm_clk)
> return true;
> }
>
> +static bool __kona_clk_init(struct kona_clk *bcm_clk);
> +static bool __kona_prereq_init(struct kona_clk *bcm_clk)
> +{
> + struct clk *clk;
> + struct clk_hw *hw;
> + struct kona_clk *prereq;
> +
> + BUG_ON(clk_is_initialized(bcm_clk));
> +
> + if (!bcm_clk->p.prereq)
> + return true;
> +
> + clk = clk_get(NULL, bcm_clk->p.prereq);
The clkdev global namespace is getting polluted with all of these new
prereq clocks. If there was an associated struct device *dev with them
then it wouldn't be a problem, but you might get collisions with other
clock drivers that also use NULL for the device.
It would be a lot nicer for the clocks that require a prereq clock to
just use clk_get(dev, "well_known_name"); in the same way that drivers
use it, without considering it a special case.
> + if (IS_ERR(clk)) {
> + pr_err("%s: unable to get prereq clock %s for %s\n",
> + __func__, bcm_clk->p.prereq, bcm_clk->init_data.name);
> + return false;
> + }
> + hw = __clk_get_hw(clk);
> + if (!hw) {
> + pr_err("%s: null hw pointer for clock %s\n", __func__,
> + bcm_clk->init_data.name);
> + return false;
> + }
> + prereq = to_kona_clk(hw);
> + if (prereq->ccu != bcm_clk->ccu) {
> + pr_err("%s: prereq clock %s CCU different for clock %s\n",
> + __func__, bcm_clk->p.prereq, bcm_clk->init_data.name);
> + return false;
> + }
> +
> + /* Initialize the prerequisite clock first */
> + if (!__kona_clk_init(prereq)) {
> + pr_err("%s: failed to init prereq %s for clock %s\n",
> + __func__, bcm_clk->p.prereq, bcm_clk->init_data.name);
> + return false;
> + }
> + bcm_clk->p.prereq_clk = clk;
The above seems like a lot effort to go to. Why not skip all of this and
just implement the prerequisite logic in the .enable & .disable
callbacks? E.g. your kona clk .enable callback would look like:
diff --git a/drivers/clk/bcm/clk-kona.c b/drivers/clk/bcm/clk-kona.c
index d603c4e..51f35b4 100644
--- a/drivers/clk/bcm/clk-kona.c
+++ b/drivers/clk/bcm/clk-kona.c
@@ -987,6 +987,12 @@ static int kona_peri_clk_enable(struct clk_hw *hw)
{
struct kona_clk *bcm_clk = to_kona_clk(hw);
struct bcm_clk_gate *gate = _clk->u.peri->gate;
+ int ret;
+
+ hw->prereq_bus_clk = clk_get(hw->ccu, hw->prereq);
+ ret = clk_enable(prereq_bus_clk);
+ if (ret)
+ return ret;
return clk_gate(bcm_clk->ccu, bcm_clk->init_data.name, gate, true);
}
@@ -997,6 +1003,9 @@ static void kona_peri_clk_disable(struct clk_hw *hw)
struct bcm_clk_gate *gate = _clk->u.peri->gate;
(void)clk_gate(bcm_clk->ccu, bcm_clk->init_data.name, gate, false);
+
+ clk_disable(hw->prereq_bus_clk);
+ clk_put(hw->prereq_bus_clk);
}
static int kona_peri_clk_is_enabled(struct clk_hw *hw)
I guess it might take some trickery to get clk_get to work like that.
Let me know if I've completely lost the plot.
Regards,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/2] irqchip: Broadcom Set Top Box Level-2 interrupt controller
Hi Thomas, Jason, This patch set adds an irqchip driver for the Broadcom Set Top Box Level-2 interrupt controller hardware, as well as a corresponding Device Tree binding document. Thanks! Florian Fainelli (2): irqchip: add Broadcom Set Top Box Level-2 interrupt controller Documentation: add Broadcom STB Level-2 interrupt controller binding .../bindings/interrupt-controller/brcm,l2-intc.txt | 29 +++ drivers/irqchip/Kconfig| 6 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-brcmstb-l2.c | 231 + 4 files changed, 267 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt create mode 100644 drivers/irqchip/irq-brcmstb-l2.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/2] Documentation: add Broadcom STB Level-2 interrupt controller binding
This patch adds the Device Tree binding document for the Broadcom
Set-top-box Level 2 interrupt controller hardware.
Signed-off-by: Brian Norris
Signed-off-by: Florian Fainelli
---
No changes in v2 or v3, respin
.../bindings/interrupt-controller/brcm,l2-intc.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
new file mode 100644
index ..448273a30a11
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
@@ -0,0 +1,29 @@
+Broadcom Generic Level 2 Interrupt Controller
+
+Required properties:
+
+- compatible: should be "brcm,l2-intc"
+- reg: specifies the base physical address and size of the registers
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: specifies the number of cells needed to encode an
+ interrupt source. Should be 1.
+- interrupt-parent: specifies the phandle to the parent interrupt controller
+ this controller is cacaded from
+- interrupts: specifies the interrupt line in the interrupt-parent irq space
+ to be used for cascading
+
+Optional properties:
+
+- brcm,irq-can-wake: If present, this means the L2 controller can be used as a
+ wakeup source for system suspend/resume.
+
+Example:
+
+hif_intr2_intc: interrupt-controller@f0441000 {
+ compatible = "brcm,l2-intc";
+ reg = <0xf0441000 0x30>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = <0x0 0x20 0x0>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] irqchip: add Broadcom Set Top Box Level-2 interrupt controller
This patch adds support for the Level-2 interrupt controller hardware
found in Broadcom Set Top Box System-on-a-Chip devices. This interrupt
controller is implemented using the generic IRQ chip driver with
separate enable and disable registers.
Signed-off-by: Brian Norris
Signed-off-by: Florian Fainelli
---
Changes in v3:
- use irq_desc_get_chip as suggested by Thomas
Changes in v2:
- fixed error path if we could not remap registers
drivers/irqchip/Kconfig | 6 ++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-brcmstb-l2.c | 202 +++
3 files changed, 209 insertions(+)
create mode 100644 drivers/irqchip/irq-brcmstb-l2.c
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index d770f7406631..bbb746e35500 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -30,6 +30,12 @@ config ARM_VIC_NR
The maximum number of VICs available in the system, for
power management.
+config BRCMSTB_L2_IRQ
+ bool
+ depends on ARM
+ select GENERIC_IRQ_CHIP
+ select IRQ_DOMAIN
+
config DW_APB_ICTL
bool
select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index f180f8d5fb7b..62a13e5ef98f 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_TB10X_IRQC) += irq-tb10x.o
obj-$(CONFIG_XTENSA) += irq-xtensa-pic.o
obj-$(CONFIG_XTENSA_MX)+= irq-xtensa-mx.o
obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
+obj-$(CONFIG_BRCMSTB_L2_IRQ) += irq-brcmstb-l2.o
diff --git a/drivers/irqchip/irq-brcmstb-l2.c b/drivers/irqchip/irq-brcmstb-l2.c
new file mode 100644
index ..8ee2a36d5840
--- /dev/null
+++ b/drivers/irqchip/irq-brcmstb-l2.c
@@ -0,0 +1,202 @@
+/*
+ * Generic Broadcom Set Top Box Level 2 Interrupt controller driver
+ *
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "irqchip.h"
+
+/* Register offsets in the L2 interrupt controller */
+#define CPU_STATUS 0x00
+#define CPU_SET0x04
+#define CPU_CLEAR 0x08
+#define CPU_MASK_STATUS0x0c
+#define CPU_MASK_SET 0x10
+#define CPU_MASK_CLEAR 0x14
+
+/* L2 intc private data structure */
+struct brcmstb_l2_intc_data {
+ int parent_irq;
+ void __iomem *base;
+ struct irq_domain *domain;
+ bool can_wake;
+ u32 saved_mask; /* for suspend/resume */
+};
+
+static void brcmstb_l2_intc_irq_handle(unsigned int irq, struct irq_desc *desc)
+{
+ struct brcmstb_l2_intc_data *b = irq_desc_get_handler_data(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ u32 status;
+
+ chained_irq_enter(chip, desc);
+
+ status = __raw_readl(b->base + CPU_STATUS) &
+ ~(__raw_readl(b->base + CPU_MASK_STATUS));
+
+ if (status == 0) {
+ do_bad_IRQ(irq, desc);
+ goto out;
+ }
+
+ do {
+ irq = ffs(status) - 1;
+ /* ack at our level */
+ __raw_writel(1 << irq, b->base + CPU_CLEAR);
+ status &= ~(1 << irq);
+ generic_handle_irq(irq_find_mapping(b->domain, irq));
+ } while (status);
+out:
+ chained_irq_exit(chip, desc);
+}
+
+static void brcmstb_l2_intc_suspend(struct irq_data *d)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct brcmstb_l2_intc_data *b = gc->private;
+
+ irq_gc_lock(gc);
+ /* Save the current mask */
+ b->saved_mask = __raw_readl(b->base + CPU_MASK_STATUS);
+
+ if (b->can_wake) {
+ /* Program the wakeup mask */
+ __raw_writel(~gc->wake_active, b->base + CPU_MASK_SET);
+ __raw_writel(gc->wake_active, b->base + CPU_MASK_CLEAR);
+ }
+ irq_gc_unlock(gc);
+}
+
+static void brcmstb_l2_intc_resume(struct irq_data *d)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct brcmstb_l2_intc_data *b = gc->private;
+
+ irq_gc_lock(gc);
+ /* Clear unmasked non-wakeup interrupts */
+ __raw_writel(~b->saved_mask & ~gc->wake_active, b->base + CPU_CLEAR);
+
+ /* Restore the saved mask */
+ __raw_writel(b->saved_mask, b->base +
Re: mm: NULL ptr deref in remove_migration_pte
Ping? On 05/05/2014 11:51 AM, Sasha Levin wrote: > Did anyone have a chance to look at it? I still see it in -next. > > > Thanks, > Sasha > > On 04/16/2014 10:59 AM, Sasha Levin wrote: >> Hi all, >> >> While fuzzing with trinity inside a KVM tools guest running latest -next >> kernel I've stumbled on the following: >> >> [ 2552.313602] BUG: unable to handle kernel NULL pointer dereference at >> 0018 >> [ 2552.315878] IP: __lock_acquire (kernel/locking/lockdep.c:3070 >> (discriminator 1)) >> [ 2552.315878] PGD 465836067 PUD 465837067 PMD 0 >> [ 2552.315878] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC >> [ 2552.315878] Dumping ftrace buffer: >> [ 2552.315878](ftrace buffer empty) >> [ 2552.315878] Modules linked in: >> [ 2552.315878] CPU: 6 PID: 16173 Comm: trinity-c364 Tainted: GW >> 3.15.0-rc1-next-20140415-sasha-00020-gaa90d09 #398 >> [ 2552.315878] task: 88046548b000 ti: 88044e532000 task.ti: >> 88044e532000 >> [ 2552.320286] RIP: __lock_acquire (kernel/locking/lockdep.c:3070 >> (discriminator 1)) >> [ 2552.320286] RSP: 0018:88044e5339c8 EFLAGS: 00010002 >> [ 2552.320286] RAX: 0082 RBX: 88046548b000 RCX: >> >> [ 2552.320286] RDX: RSI: RDI: >> 0018 >> [ 2552.320286] RBP: 88044e533ab8 R08: 0001 R09: >> >> [ 2552.320286] R10: 88046548b000 R11: 0001 R12: >> >> [ 2552.320286] R13: 0018 R14: R15: >> >> [ 2552.320286] FS: 7fd286a9a700() GS:88018b00() >> knlGS: >> [ 2552.320286] CS: 0010 DS: ES: CR0: 8005003b >> [ 2552.320286] CR2: 0018 CR3: 000442c17000 CR4: >> 06a0 >> [ 2552.320286] DR0: 00695000 DR1: DR2: >> >> [ 2552.320286] DR3: DR6: 0ff0 DR7: >> 0600 >> [ 2552.320286] Stack: >> [ 2552.320286] 88044e5339e8 9f56e761 >> 880315c13000 >> [ 2552.320286] 88044e533a38 9c193f0d 9c193e34 >> 8804654e8000 >> [ 2552.320286] 8804654e8000 0001 88046548b000 >> 0007 >> [ 2552.320286] Call Trace: >> [ 2552.320286] ? _raw_spin_unlock_irq (arch/x86/include/asm/preempt.h:98 >> include/linux/spinlock_api_smp.h:169 kernel/locking/spinlock.c:199) >> [ 2552.320286] ? finish_task_switch (include/linux/tick.h:206 >> kernel/sched/core.c:2163) >> [ 2552.320286] ? finish_task_switch (arch/x86/include/asm/current.h:14 >> kernel/sched/sched.h:993 kernel/sched/core.c:2145) >> [ 2552.320286] ? retint_restore_args (arch/x86/kernel/entry_64.S:1040) >> [ 2552.320286] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63) >> [ 2552.320286] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2557 >> kernel/locking/lockdep.c:2599) >> [ 2552.320286] lock_acquire (arch/x86/include/asm/current.h:14 >> kernel/locking/lockdep.c:3602) >> [ 2552.320286] ? remove_migration_pte (mm/migrate.c:137) >> [ 2552.320286] ? retint_restore_args (arch/x86/kernel/entry_64.S:1040) >> [ 2552.320286] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 >> kernel/locking/spinlock.c:151) >> [ 2552.320286] ? remove_migration_pte (mm/migrate.c:137) >> [ 2552.320286] remove_migration_pte (mm/migrate.c:137) >> [ 2552.320286] rmap_walk (mm/rmap.c:1628 mm/rmap.c:1699) >> [ 2552.320286] remove_migration_ptes (mm/migrate.c:224) >> [ 2552.320286] ? new_page_node (mm/migrate.c:107) >> [ 2552.320286] ? remove_migration_pte (mm/migrate.c:195) >> [ 2552.320286] migrate_pages (mm/migrate.c:922 mm/migrate.c:960 >> mm/migrate.c:1126) >> [ 2552.320286] ? perf_trace_mm_numa_migrate_ratelimit (mm/migrate.c:1574) >> [ 2552.320286] migrate_misplaced_page (mm/migrate.c:1733) >> [ 2552.320286] __handle_mm_fault (mm/memory.c:3762 mm/memory.c:3812 >> mm/memory.c:3925) >> [ 2552.320286] ? __const_udelay (arch/x86/lib/delay.c:126) >> [ 2552.320286] ? __rcu_read_unlock (kernel/rcu/update.c:97) >> [ 2552.320286] handle_mm_fault (mm/memory.c:3948) >> [ 2552.320286] __get_user_pages (mm/memory.c:1851) >> [ 2552.320286] ? preempt_count_sub (kernel/sched/core.c:2527) >> [ 2552.320286] __mlock_vma_pages_range (mm/mlock.c:255) >> [ 2552.320286] __mm_populate (mm/mlock.c:711) >> [ 2552.320286] SyS_mlockall (include/linux/mm.h:1799 mm/mlock.c:817 >> mm/mlock.c:791) >> [ 2552.320286] tracesys (arch/x86/kernel/entry_64.S:749) >> [ 2552.320286] Code: 85 2d 1e 00 00 48 c7 c1 d7 68 6c a0 48 c7 c2 47 11 6c >> a0 31 c0 be fa 0b 00 00 48 c7 c7 91 68 6c a0 e8 1c 6d f9 ff e9 07 1e 00 00 >> <49> 81 7d 00 80 31 76 a2 b8 00 00 00 00 44 0f 44 c0 eb 07 0f 1f >> [ 2552.320286] RIP __lock_acquire (kernel/locking/lockdep.c:3070 >> (discriminator 1)) >> [ 2552.320286] RSP >> [ 2552.320286] CR2: 0018 >> >> >> Thanks, >> Sasha >> > -- To unsubscribe from this list: send the line "unsubscribe
Re: slab_common: fix the check for duplicate slab names
On Fri, May 23 2014 at 5:28pm -0400, Pekka Enberg wrote: > On 05/23/2014 11:16 PM, Mike Snitzer wrote: > >On Tue, Mar 25 2014 at 2:07pm -0400, > >Christoph Lameter wrote: > > > >>On Tue, 25 Mar 2014, Mike Snitzer wrote: > >> > >>>This patch still isn't upstream. Who should be shepherding it to Linus? > >>Pekka usually does that. > >> > >>Acked-by: Christoph Lameter > >This still hasn't gotten upstream. > > > >Pekka, any chance you can pick it up? Here it is in dm-devel's > >kernel.org patchwork: https://patchwork.kernel.org/patch/3768901/ > > > >(Though it looks like it needs to be rebased due to the recent commit > >794b1248, should Mikulas rebase and re-send?) > > I applied it and fixed the conflict by hand. > > Please double-check commit 694617474e33b8603fc76e090ed7d09376514b1a > in my tree: > > https://git.kernel.org/cgit/linux/kernel/git/penberg/linux.git/ Looks good, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] clk: bcm281xx: add an initialized flag
Quoting Alex Elder (2014-05-20 05:52:38)
> Add a flag that tracks whether a clock has already been initialized.
> This will be used by the next patch to avoid initializing a clock
> more than once when it's listed as a prerequisite.
>
> Signed-off-by: Alex Elder
> ---
> drivers/clk/bcm/clk-kona.c | 17 +++--
> drivers/clk/bcm/clk-kona.h | 7 +++
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/bcm/clk-kona.c b/drivers/clk/bcm/clk-kona.c
> index d603c4e..d8a7f38 100644
> --- a/drivers/clk/bcm/clk-kona.c
> +++ b/drivers/clk/bcm/clk-kona.c
> @@ -27,6 +27,9 @@
> #define CCU_ACCESS_PASSWORD 0xA5A500
> #define CLK_GATE_DELAY_LOOP 2000
>
> +#define clk_is_initialized(_clk) FLAG_TEST((_clk), KONA, INITIALIZED)
> +#define clk_set_initialized(_clk) FLAG_SET((_clk), KONA, INITIALIZED)
> +
> /* Bitfield operations */
>
> /* Produces a mask of set bits covering a range of a 32-bit value */
> @@ -1194,13 +1197,23 @@ static bool __peri_clk_init(struct kona_clk *bcm_clk)
>
> static bool __kona_clk_init(struct kona_clk *bcm_clk)
> {
> + bool ret;
> +
> + if (clk_is_initialized(bcm_clk))
> + return true;
> +
> switch (bcm_clk->type) {
> case bcm_clk_peri:
> - return __peri_clk_init(bcm_clk);
> + ret = __peri_clk_init(bcm_clk);
Hi Alex,
Going through this code, it's a bit hard to keep up ;-)
Does the call to __peri_clk_init enable the prereq clocks? If so, is
their clk->prepare_count and clk->enable_count properly incremented?
Thanks,
Mike
> + break;
> default:
> + ret = false;
> BUG();
> }
> - return -EINVAL;
> + if (ret)
> + clk_set_initialized(bcm_clk);
> +
> + return ret;
> }
>
> /* Set a CCU and all its clocks into their desired initial state */
> diff --git a/drivers/clk/bcm/clk-kona.h b/drivers/clk/bcm/clk-kona.h
> index 2537b30..10e238d 100644
> --- a/drivers/clk/bcm/clk-kona.h
> +++ b/drivers/clk/bcm/clk-kona.h
> @@ -406,6 +406,7 @@ struct kona_clk {
> struct clk_init_data init_data; /* includes name of this clock */
> struct ccu_data *ccu; /* ccu this clock is associated with */
> enum bcm_clk_type type;
> + u32 flags; /* BCM_CLK_KONA_FLAGS_* below */
> union {
> void *data;
> struct peri_clk_data *peri;
> @@ -414,6 +415,12 @@ struct kona_clk {
> #define to_kona_clk(_hw) \
> container_of(_hw, struct kona_clk, hw)
>
> +/*
> + * Kona clock flags:
> + * INITIALIZED clock has been initialized already
> + */
> +#define BCM_CLK_KONA_FLAGS_INITIALIZED ((u32)1 << 0) /* Clock initialized
> */
> +
> /* Initialization macro for an entry in a CCU's kona_clks[] array. */
> #define KONA_CLK(_ccu_name, _clk_name, _type) \
> { \
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pinctrl: msm: Add missing sdc1 and sdc3 groups for apq8064
Signed-off-by: Bjorn Andersson
---
drivers/pinctrl/pinctrl-apq8064.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-apq8064.c
b/drivers/pinctrl/pinctrl-apq8064.c
index 23c4c21..3adf9fd 100644
--- a/drivers/pinctrl/pinctrl-apq8064.c
+++ b/drivers/pinctrl/pinctrl-apq8064.c
@@ -110,6 +110,13 @@ static const struct pinctrl_pin_desc apq8064_pins[] = {
PINCTRL_PIN(87, "GPIO_87"),
PINCTRL_PIN(88, "GPIO_88"),
PINCTRL_PIN(89, "GPIO_89"),
+
+ PINCTRL_PIN(90, "SDC1_CLK"),
+ PINCTRL_PIN(91, "SDC1_CMD"),
+ PINCTRL_PIN(92, "SDC1_DATA"),
+ PINCTRL_PIN(93, "SDC3_CLK"),
+ PINCTRL_PIN(94, "SDC3_CMD"),
+ PINCTRL_PIN(95, "SDC3_DATA"),
};
#define DECLARE_APQ_GPIO_PINS(pin) static const unsigned int
gpio##pin##_pins[] = { pin }
@@ -207,9 +214,9 @@ DECLARE_APQ_GPIO_PINS(89);
static const unsigned int sdc1_clk_pins[] = { 90 };
static const unsigned int sdc1_cmd_pins[] = { 91 };
static const unsigned int sdc1_data_pins[] = { 92 };
-static const unsigned int sdc2_clk_pins[] = { 93 };
-static const unsigned int sdc2_cmd_pins[] = { 94 };
-static const unsigned int sdc2_data_pins[] = { 95 };
+static const unsigned int sdc3_clk_pins[] = { 93 };
+static const unsigned int sdc3_cmd_pins[] = { 94 };
+static const unsigned int sdc3_data_pins[] = { 95 };
#define FUNCTION(fname)\
[APQ_MUX_##fname] = { \
@@ -550,6 +557,14 @@ static const struct msm_pingroup apq8064_groups[] = {
PINGROUP(87, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA),
PINGROUP(88, usb2_hsic, NA, NA, NA, NA, NA, NA, NA, NA, NA),
PINGROUP(89, usb2_hsic, NA, NA, NA, NA, NA, NA, NA, NA, NA),
+
+ SDC_PINGROUP(sdc1_clk, 0x20a0, 13, 6),
+ SDC_PINGROUP(sdc1_cmd, 0x20a0, 11, 3),
+ SDC_PINGROUP(sdc1_data, 0x20a0, 9, 0),
+
+ SDC_PINGROUP(sdc3_clk, 0x20a4, 14, 6),
+ SDC_PINGROUP(sdc3_cmd, 0x20a4, 11, 3),
+ SDC_PINGROUP(sdc3_data, 0x20a4, 9, 0),
};
#define NUM_GPIO_PINGROUPS 90
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 3/4] x86/PCI: Stop enabling ECS for AMD CPUs after Fam16h
On 5/22/2014 9:54 PM, Bjorn Helgaas wrote: I've been poking around for recent dmesg logs that contain "PCI: Using configuration type 1 for extended access", and there are quite a few. In most cases there*is* an MCFG table, but apparently we decide not to use it for some reason (unfortunately we don't print the specific reason). One example is at https://bugzilla.kernel.org/show_bug.cgi?id=68591 . I'm going to go out on a limb and guess that Windows does not enable ECS, so it probably uses ECAM. Therefore, I suspect Linux's parsing of MCFG is broken in some way, and we probably*could* use ECAM in all these cases I'm seeing. It would probably be prudent to figure out why Linux is rejecting these MCFG tables. We'll probably see similar tables on Fam17h systems, and if we continue rejecting them, and we don't turn on ECS, we won't be able to access extended config space. I opened a bugzilla for this issue: https://bugzilla.kernel.org/show_bug.cgi?id=76771 I'm wavering on whether it's a good idea to put this patch in before understanding the issue. As much as I'd like to stop fiddling with ECS, we'd likely end up with a v3.15 where extended config space doesn't work on some Fam17h systems. So, I have located a system which presents issue with MMCONFIG. Here is my investigation: DEBUG: pci_io_ecs_init: pci_probe = 4000f ACPI: bus type PCI registered DEBUG: -> pci_mmcfg_early_init DEBUG: pci_parse_mcfg PCI: MMCONFIG for domain [bus 00-01] at [mem 0xe000-0xe01f] (base 0xe000) DEBUG: pci_mmcfg_check_reserved DEBUG: is_mmconf_reserved: method = E820 PCI: not using MMCONFIG DEBUG: pci_direct_init PCI: Using configuration type 1 for base access PCI: Using configuration type 1 for extended access ACPI: Added _OSI(Module Device) ACPI: Added _OSI(Processor Device) ACPI: Added _OSI(3.0 _SCP Extensions) ACPI: Added _OSI(Processor Aggregator Device) [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored \_SB_:_OSC invalid UUID _OSC request data:1 1f ACPI: Interpreter enabled ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20140214/hwxface-580) ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20140214/hwxface-580) ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S4_] (20140214/hwxface-580) ACPI: (supports S0 S3 S5) ACPI: Using IOAPIC for interrupt routing DEBUG: > pci_mmcfg_late_init DEBUG: pci_parse_mcfg PCI: MMCONFIG for domain [bus 00-01] at [mem 0xe000-0xe01f] (base 0xe000) DEBUG: pci_mmcfg_check_reserved DEBUG: is_mmconf_reserved: method = ACPI motherboard resources PCI: MMCONFIG at [mem 0xe000-0xe01f] reserved in ACPI motherboard resources During pci_mmcfg_early_init(), the MMCONFIG failed because the range 0xe000 is not showing as reserved in the E820 mapping. Here is the snippet of E820 mapping from the system: BIOS-e820: [mem 0xc7eb-0xc7ec0fff] ACPI data BIOS-e820: [mem 0xc7ec1000-0xc7ec2fff] ACPI NVS BIOS-e820: [mem 0xc7ec3000-0xc7efefff] reserved BIOS-e820: [mem 0xc7f0-0xc7ff] reserved BIOS-e820: [mem 0xfec0-0xfec0] reserved However, during pci_mmcfg_late_init(), the area is reserved in the "ACPI motherboard resources", and the pci_mmcfg_check_reserved() does not fail here. But this is too late since we already setup the "raw_pci_ext_ops" in the "arch/x86/pci/direct.c: pci_direct_init()" (during to use the IO_ECS. Suravee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] clk: u300: Terminate of match table
Failure to terminate this match table can lead to boot failures
depending on where the compiler places the match table.
Cc: Linus Walleij
Signed-off-by: Stephen Boyd
---
drivers/clk/clk-u300.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/clk-u300.c b/drivers/clk/clk-u300.c
index 3efbdd078d14..406bfc1375b2 100644
--- a/drivers/clk/clk-u300.c
+++ b/drivers/clk/clk-u300.c
@@ -1168,6 +1168,7 @@ static const struct of_device_id u300_clk_match[]
__initconst = {
.compatible = "stericsson,u300-syscon-mclk",
.data = of_u300_syscon_mclk_init,
},
+ {}
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] clk: st: Terminate of match table
Failure to terminate this match table can lead to boot failures
depending on where the compiler places the match table.
Cc: Gabriel FERNANDEZ
Signed-off-by: Stephen Boyd
---
drivers/clk/st/clkgen-pll.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/st/clkgen-pll.c b/drivers/clk/st/clkgen-pll.c
index bca0a0badbfa..2f7da5faa6d7 100644
--- a/drivers/clk/st/clkgen-pll.c
+++ b/drivers/clk/st/clkgen-pll.c
@@ -653,6 +653,7 @@ static struct of_device_id c32_gpu_pll_of_match[] = {
.compatible = "st,stih416-gpu-pll-c32",
.data = _pll1200c32_gpu_416,
},
+ {}
};
static void __init clkgengpu_c32_pll_setup(struct device_node *np)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ASoC: pxa: pxa-ssp: Terminate of match table
Failure to terminate this match table can lead to boot failures
depending on where the compiler places the match table.
Cc: Daniel Mack
Signed-off-by: Stephen Boyd
---
sound/soc/pxa/pxa-ssp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/pxa/pxa-ssp.c b/sound/soc/pxa/pxa-ssp.c
index a3119a00d8fa..dd35e7be1d8b 100644
--- a/sound/soc/pxa/pxa-ssp.c
+++ b/sound/soc/pxa/pxa-ssp.c
@@ -810,6 +810,7 @@ static const struct snd_soc_component_driver
pxa_ssp_component = {
#ifdef CONFIG_OF
static const struct of_device_id pxa_ssp_of_ids[] = {
{ .compatible = "mrvl,pxa-ssp-dai" },
+ {}
};
#endif
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mfd: tps65218: Terminate of match table
Failure to terminate this match table can lead to boot failures
depending on where the compiler places the match table.
Cc: Keerthy
Signed-off-by: Stephen Boyd
---
drivers/mfd/tps65218.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index a74bfb59f18f..0d256cb002eb 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -197,6 +197,7 @@ static struct regmap_irq_chip tps65218_irq_chip = {
static const struct of_device_id of_tps65218_match_table[] = {
{ .compatible = "ti,tps65218", },
+ {}
};
static int tps65218_probe(struct i2c_client *client,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging/mt29f_spinand: Terminate of match table
Failure to terminate this match table can lead to boot failures
depending on where the compiler places the match table.
Cc: Kamlakant Patel
Cc: Mona Anonuevo
Cc: linux-...@lists.infradead.org
Signed-off-by: Stephen Boyd
---
drivers/staging/mt29f_spinand/mt29f_spinand.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c
b/drivers/staging/mt29f_spinand/mt29f_spinand.c
index 51dbc13e757f..5a40925680ac 100644
--- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -924,6 +924,7 @@ static int spinand_remove(struct spi_device *spi)
static const struct of_device_id spinand_dt[] = {
{ .compatible = "spinand,mt29f", },
+ {}
};
/*
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] arm64: enable context tracking
Mark Rutland writes: > On Fri, May 23, 2014 at 03:51:07PM +0100, Catalin Marinas wrote: >> On Fri, May 23, 2014 at 01:11:38AM +0100, Kevin Hilman wrote: >> > Christopher Covington writes: >> > > On 05/22/2014 03:27 PM, Larry Bassel wrote: >> > >> Make calls to ct_user_enter when the kernel is exited >> > >> and ct_user_exit when the kernel is entered (in el0_da, >> > >> el0_ia, el0_svc, el0_irq and all of the "error" paths). >> > >> >> > >> These macros expand to function calls which will only work >> > >> properly if el0_sync and related code has been rearranged >> > >> (in a previous patch of this series). >> > >> >> > >> The calls to ct_user_exit are made after hw debugging has been >> > >> enabled (enable_dbg_and_irq). >> > >> >> > >> The call to ct_user_enter is made at the beginning of the >> > >> kernel_exit macro. >> > >> >> > >> This patch is based on earlier work by Kevin Hilman. >> > >> Save/restore optimizations were also done by Kevin. >> > > >> > >> --- a/arch/arm64/kernel/entry.S >> > >> +++ b/arch/arm64/kernel/entry.S >> > >> @@ -30,6 +30,44 @@ >> > >> #include >> > >> >> > >> /* >> > >> + * Context tracking subsystem. Used to instrument transitions >> > >> + * between user and kernel mode. >> > >> + */ >> > >> + .macro ct_user_exit, restore = 0 >> > >> +#ifdef CONFIG_CONTEXT_TRACKING >> > >> + bl context_tracking_user_exit >> > >> + .if \restore == 1 >> > >> + /* >> > >> +* Save/restore needed during syscalls. Restore syscall >> > >> arguments from >> > >> +* the values already saved on stack during kernel_entry. >> > >> +*/ >> > >> + ldp x0, x1, [sp] >> > >> + ldp x2, x3, [sp, #S_X2] >> > >> + ldp x4, x5, [sp, #S_X4] >> > >> + ldp x6, x7, [sp, #S_X6] >> > >> + .endif >> > >> +#endif >> > >> + .endm >> > >> + >> > >> + .macro ct_user_enter, save = 0 >> > >> +#ifdef CONFIG_CONTEXT_TRACKING >> > >> + .if \save == 1 >> > >> + /* >> > >> +* Save/restore only needed on syscall fastpath, which uses >> > >> +* x0-x2. >> > >> +*/ >> > >> + pushx2, x3 >> > > >> > > Why is x3 saved? >> > >> > I'll respond here since I worked with Larry on the context save/restore >> > part. >> > >> > [insert rather embarassing disclamer of ignorance of arm64 assembly] >> > >> > Based on my reading of the code, I figured only x0-x2 needed to be >> > saved. However, based on some experiments with intentionally clobbering >> > the registers[1] (as suggested by Mark Rutland) in order to make sure >> > we're saving/restoring the right things, I discovered x3 was needed too >> > (I missed updating the comment to mention x0-x3.) >> > >> > Maybe Will/Catalin/Mark R. can shed some light here? >> >> I haven't checked all the code paths but at least for pushing onto the >> stack we must keep it 16-bytes aligned (architecture requirement). > > Sure -- if modifying the stack we need to push/pop pairs of registers to > keep it aligned. It might be better to use xzr as the dummy value in > that case to make it clear that the value doesn't really matter. > > That said, ct_user_enter is only called in kernel_exit before we restore > the values off the stack, and the only register I can spot that we need > to preserve is x0 for the syscall return value. I can't see x1 or x2 > being used any more specially than the rest of the remaining registers. > Am I missing something, I don't think you're missing something. I had thought my experiment in clobbering registers uncovered that x1-x3 were also in use somewhere, but in trying to reproduce that now, it's clear only x0 is important. > or would it be sufficient to do the following? > push x0, xzr > blcontext_tacking_user_enter > pop x0, xzr Yes, this seems to work. Following Will's suggestion of using a callee-saved register to save x0, the updated version now looks like this: .macro ct_user_enter, save = 0 #ifdef CONFIG_CONTEXT_TRACKING .if \save == 1 /* * We only have to save/restore x0 on the fast syscall path where * x0 contains the syscall return. */ mov x19, x0 .endif bl context_tracking_user_enter .if \save == 1 mov x0, x19 .endif #endif .endm We'll update this as well as address the comments on PATCH 1/2 and send a v5. Thanks guys for the review and guidance as I'm wandering a bit in the dark here in arm64 assembler land. Cheers, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Timekeeping items for 3.16
Hey Thomas, Ingo, Just wanted to send in my 3.16 queue so it can get some time in -next. Nothing particularly exciting, just a few cleanups. Let me know if you have any objections or comments. thanks -john The following changes since commit 4d0fa8a0f01272d4de33704f20303dcecdb55df1: Merge tag 'gpio-v3.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio (2014-04-22 09:28:02 -0700) are available in the git repository at: git://git.linaro.org/people/john.stultz/linux.git fortglx/3.16/time for you to fetch changes up to ea54bca3aab3468daf1c37d15047ee66bca8760d: ntp: Make is_error_status() use its argument (2014-05-12 11:01:08 -0700) Fabian Frederick (1): ntp: Convert simple_strtol to kstrtol George Spelvin (1): ntp: Make is_error_status() use its argument Stephen Boyd (1): sched_clock: Remove deprecated setup_sched_clock() API include/linux/sched_clock.h | 1 - kernel/time/ntp.c | 17 ++--- kernel/time/sched_clock.c | 13 - 3 files changed, 10 insertions(+), 21 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scripts/dtc: pad DTBs to facilitate later modification
By default, add some padding to the DT blobs to facilitate later patching. An example need for DTB patching is the need to modifiy the command line on platforms where ATAGS are not (or cannot) be used to pass the commandline. For example, we do not support a big-endian kernel reading ATAGS from a little-endian u-boot, so the only way to pass a command line in the DT. Also, without ATAG support (or if u-boot was built without CONFIG_INITRD_TAG) the only way to pass an initrd is by adding an initrd= option to command line (in the DT). Therefore, to facilitate adding to the DT command line directly in the DTB, add some padding. Cc: Nicolas Pitre Cc: Stephen Warren Cc: Thomas Petazzoni Signed-off-by: Kevin Hilman --- I kinda pulled 64 bytes out of the air here since it's enough to add some common things to the commandline like debug, earlyprink initrd=,, etc., but I'm certainlly not opposed to more padding. scripts/Makefile.lib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 6a5b0decb797..d7a57c2620f3 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -264,7 +264,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb quiet_cmd_dtc = DTC $@ cmd_dtc = $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \ - $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 \ + $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 -p 64 \ -i $(dir $<) $(DTC_FLAGS) \ -d $(depfile).dtc.tmp $(dtc-tmp) ; \ cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile) -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] coccinelle: Check for missing NULL terminators in of_device_id tables
Failure to terminate an of_device_id table can lead to confusing
failures depending on where the compiler places the array. Add a
check to make sure these tables are terminated. Thanks to Mitchel
Humpherys for coming up with the initial pattern.
Cc: Mitchel Humpherys
Cc: Julia Lawall
Cc: Gilles Muller
Cc: Nicolas Palix
Cc: Grant Likely
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Signed-off-by: Stephen Boyd
---
scripts/coccinelle/misc/of_table.cocci | 81 ++
1 file changed, 81 insertions(+)
create mode 100644 scripts/coccinelle/misc/of_table.cocci
diff --git a/scripts/coccinelle/misc/of_table.cocci
b/scripts/coccinelle/misc/of_table.cocci
new file mode 100644
index ..da8bfa69fa3e
--- /dev/null
+++ b/scripts/coccinelle/misc/of_table.cocci
@@ -0,0 +1,81 @@
+/// Make sure of_device_id tables are NULL terminated
+//
+// Keywords: of_table
+// Confidence: Medium
+// Options: --include-headers
+
+virtual patch
+virtual context
+virtual org
+virtual report
+
+@bad_of_table exists@
+identifier var, arr;
+expression E;
+@@
+... struct of_device_id arr[] = {
+ ...,
+ {
+ ...,
+ .var = E,
+ ...
+ }
+};
+
+@depends on bad_of_table && context@
+identifier var, arr;
+expression E;
+@@
+ ... struct of_device_id arr[] = {
+ ...,
+ {
+ ...,
+* .var = E,
+ ...
+ }
+};
+
+@depends on bad_of_table && patch@
+identifier var, arr;
+expression E;
+@@
+... struct of_device_id arr[] = {
+ ...,
+ {
+ ...,
+ .var = E,
+ ...
+- }
++ },
++ { }
+};
+
+@r depends on bad_of_table exists@
+position p1;
+identifier var, arr;
+expression E;
+@@
+... struct of_device_id arr[] = {
+ ...,
+ {
+ ...,
+ .var = E,
+ ...
+ }
+ @p1
+};
+
+@script:python depends on org@
+p1 << r.p1;
+arr << r.arr;
+@@
+
+cocci.print_main(arr,p1)
+
+@script:python depends on report@
+p1 << r.p1;
+arr << r.arr;
+@@
+
+msg = "%s is not NULL terminated at line %s" % (arr, p1[0].line)
+coccilib.report.print_report(p1[0],msg)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] staging: panel: (coding style) Multiple assignments
Style-only modifications to comply with checkpatch.pl --strict --file.
. Breaks down compound assignments.
Signed-off-by: Dominique van den Broeck
---
Resent to lay each variable on its single row.
Other patches have been accepted.
Apply on linux-next tree, above:
commit 4151fa6adc65da14673ece623bbb2acc6936f8be
"Add linux-next specific files for 20140516"
diff --git a/drivers/staging/panel/panel.c b/drivers/staging/panel/panel.c
index 1ac5e25..8d15b04 100644
--- a/drivers/staging/panel/panel.c
+++ b/drivers/staging/panel/panel.c
@@ -664,8 +664,12 @@ static void pin_to_bits(int pin, unsigned char *d_val,
unsigned char *c_val)
{
int d_bit, c_bit, inv;
- d_val[0] = c_val[0] = d_val[1] = c_val[1] = 0;
- d_val[2] = c_val[2] = 0xFF;
+ d_val[0] = 0;
+ c_val[0] = 0;
+ d_val[1] = 0;
+ c_val[1] = 0;
+ d_val[2] = 0xFF;
+ c_val[2] = 0xFF;
if (pin == 0)
return;
@@ -674,7 +678,8 @@ static void pin_to_bits(int pin, unsigned char *d_val,
unsigned char *c_val)
if (inv)
pin = -pin;
- d_bit = c_bit = 0;
+ d_bit = 0;
+ c_bit = 0;
switch (pin) {
case PIN_STROBE:/* strobe, inverted */
@@ -867,7 +872,8 @@ static void lcd_clear_fast_s(void)
{
int pos;
- lcd_addr_x = lcd_addr_y = 0;
+ lcd_addr_x = 0;
+ lcd_addr_y = 0;
lcd_gotoxy();
spin_lock_irq(_lock);
@@ -879,7 +885,8 @@ static void lcd_clear_fast_s(void)
}
spin_unlock_irq(_lock);
- lcd_addr_x = lcd_addr_y = 0;
+ lcd_addr_x = 0;
+ lcd_addr_y = 0;
lcd_gotoxy();
}
@@ -888,7 +895,8 @@ static void lcd_clear_fast_p8(void)
{
int pos;
- lcd_addr_x = lcd_addr_y = 0;
+ lcd_addr_x = 0;
+ lcd_addr_y = 0;
lcd_gotoxy();
spin_lock_irq(_lock);
@@ -915,7 +923,8 @@ static void lcd_clear_fast_p8(void)
}
spin_unlock_irq(_lock);
- lcd_addr_x = lcd_addr_y = 0;
+ lcd_addr_x = 0;
+ lcd_addr_y = 0;
lcd_gotoxy();
}
@@ -924,7 +933,8 @@ static void lcd_clear_fast_tilcd(void)
{
int pos;
- lcd_addr_x = lcd_addr_y = 0;
+ lcd_addr_x = 0;
+ lcd_addr_y = 0;
lcd_gotoxy();
spin_lock_irq(_lock);
@@ -936,7 +946,8 @@ static void lcd_clear_fast_tilcd(void)
spin_unlock_irq(_lock);
- lcd_addr_x = lcd_addr_y = 0;
+ lcd_addr_x = 0;
+ lcd_addr_y = 0;
lcd_gotoxy();
}
@@ -944,7 +955,8 @@ static void lcd_clear_fast_tilcd(void)
static void lcd_clear_display(void)
{
lcd_write_cmd(0x01);/* clear display */
- lcd_addr_x = lcd_addr_y = 0;
+ lcd_addr_x = 0;
+ lcd_addr_y = 0;
/* we must wait a few milliseconds (15) */
long_sleep(15);
}
@@ -1292,7 +1304,8 @@ static void lcd_write_char(char c)
processed = 1;
} else if (!strcmp(lcd_escape, "[H")) {
/* cursor to home */
- lcd_addr_x = lcd_addr_y = 0;
+ lcd_addr_x = 0;
+ lcd_addr_y = 0;
lcd_gotoxy();
processed = 1;
}
@@ -1576,7 +1589,8 @@ static void lcd_init(void)
panel_lcd_print("\x1b[Lc\x1b[Lb\x1b[L*Linux-" UTS_RELEASE "\nPanel-"
PANEL_VERSION);
#endif
- lcd_addr_x = lcd_addr_y = 0;
+ lcd_addr_x = 0;
+ lcd_addr_y = 0;
/* clear the display on the next device opening */
lcd_must_clear = 1;
lcd_gotoxy();
@@ -1953,7 +1967,10 @@ static int input_name2mask(const char *name, pmask_t
*mask, pmask_t *value,
char im, om;
pmask_t m, v;
- om = im = m = v = 0ULL;
+ om = 0ULL;
+ im = 0ULL;
+ m = 0ULL;
+ v = 0ULL;
while (*name) {
int in, out, bit, neg;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] page_alloc: skip cpuset enforcement for lower zone allocations
On Fri, May 23, 2014 at 01:51:12PM -0700, David Rientjes wrote: > On Fri, 23 May 2014, Marcelo Tosatti wrote: > > > Zone specific allocations, such as GFP_DMA32, should not be restricted > > to cpusets allowed node list: the zones which such allocations demand > > might be contained in particular nodes outside the cpuset node list. > > > > The alternative would be to not perform such allocations from > > applications which are cpuset restricted, which is unrealistic. > > > > Or ensure applications that allocate from lowmem are allowed to do so, but > I understand that might be hard to make sure always happens. > > > Fixes KVM's alloc_page(gfp_mask=GFP_DMA32) with cpuset as explained. > > > > Signed-off-by: Marcelo Tosatti > > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index 5dba293..f228039 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -2698,6 +2698,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int > > order, > > unsigned int cpuset_mems_cookie; > > int alloc_flags = ALLOC_WMARK_LOW|ALLOC_CPUSET|ALLOC_FAIR; > > struct mem_cgroup *memcg = NULL; > > + nodemask_t *cpuset_mems_allowed = _current_mems_allowed; > > > > gfp_mask &= gfp_allowed_mask; > > > > @@ -2726,9 +2727,14 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int > > order, > > retry_cpuset: > > cpuset_mems_cookie = read_mems_allowed_begin(); > > > > +#ifdef CONFIG_NUMA > > + if (gfp_zone(gfp_mask) < policy_zone) > > + cpuset_mems_allowed = NULL; > > +#endif > > + > > /* The preferred zone is used for statistics later */ > > first_zones_zonelist(zonelist, high_zoneidx, > > - nodemask ? : _current_mems_allowed, > > + nodemask ? : cpuset_mems_allowed, > > _zone); > > if (!preferred_zone) > > goto out; > > > > I think this is incomplete. Correct me if I'm wrong on how this is > working: preferred_zone, today, is NULL because first_zones_zonelist() is > restricted to a cpuset.mems that does not include lowmem and your patch > fixes that. > But if the fastpath allocation with mandatory ALLOC_CPUSET > fails and we go to the slowpath, which may or may not have showed up in > your testing, there's still issues, > particularly if __GFP_WAIT and lots of > allocators do GFP_KERNEL | __GFP_DMA32. This requires ALLOC_CPUSET on all > allocations and you haven't updated __cpuset_node_allowed_softwall() with > this exception nor zlc_setup(). Yes, thanks. Can you please review updated patch below. > After that's done, I think all of this is really convoluted and deserves a > comment to describe the ALLOC_CPUSET and __GFP_DMA32 behavior. The comment at mm/mempolicy.c seems sufficient: /* Highest zone. An specific allocation for a zone below that is not policied. */ enum zone_type policy_zone = 0; > Adding Li, the cpusets maintainer, to this as well. diff --git a/kernel/cpuset.c b/kernel/cpuset.c index 3d54c41..b70a336 100644 --- a/kernel/cpuset.c +++ b/kernel/cpuset.c @@ -2392,6 +2392,10 @@ int __cpuset_node_allowed_softwall(int node, gfp_t gfp_mask) if (in_interrupt() || (gfp_mask & __GFP_THISNODE)) return 1; +#ifdef CONFIG_NUMA + if (gfp_zone(gfp_mask) < policy_zone) + return 1; +#endif might_sleep_if(!(gfp_mask & __GFP_HARDWALL)); if (node_isset(node, current->mems_allowed)) return 1; diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 5dba293..dfea3dc 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2698,6 +2698,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, unsigned int cpuset_mems_cookie; int alloc_flags = ALLOC_WMARK_LOW|ALLOC_CPUSET|ALLOC_FAIR; struct mem_cgroup *memcg = NULL; + nodemask_t *cpuset_mems_allowed = _current_mems_allowed; gfp_mask &= gfp_allowed_mask; @@ -2726,9 +2727,14 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, retry_cpuset: cpuset_mems_cookie = read_mems_allowed_begin(); +#ifdef CONFIG_NUMA + if (gfp_zone(gfp_mask) < policy_zone) + cpuset_mems_allowed = NULL; +#endif + /* The preferred zone is used for statistics later */ first_zones_zonelist(zonelist, high_zoneidx, - nodemask ? : _current_mems_allowed, + nodemask ? : cpuset_mems_allowed, _zone); if (!preferred_zone) goto out; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 13/13] mmc: mmci: Add Qcom specific pio_read function.
On 05/23/14 05:53, srinivas.kandaga...@linaro.org wrote:
> @@ -1022,6 +1025,40 @@ mmci_cmd_irq(struct mmci_host *host, struct
> mmc_command *cmd,
> }
> }
>
> +static int mmci_qcom_pio_read(struct mmci_host *host, char *buffer,
> + unsigned int remain)
> +{
> + u32 *ptr = (u32 *) buffer;
> + unsigned int count = 0;
> + unsigned int words, bytes;
> + unsigned int fsize = host->variant->fifosize;
> +
> + words = remain >> 2;
> + bytes = remain % 4;
> + /* read full words followed by leftover bytes */
> + if (words) {
> + while (readl(host->base + MMCISTATUS) & MCI_RXDATAAVLBL) {
> + *ptr = readl(host->base + MMCIFIFO + (count % fsize));
This doesn't look endianness agnostic. Shouldn't we use ioread32_rep()
to read this fifo?
> + ptr++;
> + count += 4;
> + words--;
> + if (!words)
> + break;
> + }
> + }
> +
> + if (unlikely(bytes)) {
> + unsigned char buf[4];
> + if (readl(host->base + MMCISTATUS) & MCI_RXDATAAVLBL) {
> + *buf = readl(host->base + MMCIFIFO + (count % fsize));
> + memcpy(ptr, buf, bytes);
> + count += bytes;
> + }
> + }
> +
> + return count;
> +}
> +
> static int mmci_pio_read(struct mmci_host *host, char *buffer, unsigned int
> remain)
> {
> void __iomem *base = host->base;
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/14] Add Qualcomm SD Card Controller support
On Fri, May 23, 2014 at 9:50 AM, Srinivas Kandagatla wrote: > Hi Bjorn, > > Thanks for the update. Hi Srini, After pulling in Ulfs next branch again and reapplying v3 my issues are now gone. Not sure what I screwed up when I merged v2, this seems to work just fine now. Sorry for the fuzz. I haven't done any extensive testing, but my CRC issues are definitely sorted out. I will go ahead and see if I can get external mmc working now as well. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: bcm/kona: implement determine_rate()
On 05/23/2014 06:18 PM, Mike Turquette wrote:
> Quoting Alex Elder (2014-05-20 06:24:57)
>> Implement the clk->determine_rate method for Broadcom Kona peripheral
>> clocks. This allows a peripheral clock to be re-parented in order to
>> satisfy a rate change request. This takes the place of the previous
>> kona_peri_clk_round_rate() functionality, though that function remains
>> because it is used by the new one.
>>
>> The parent clock that allows the peripheral clock to produce a rate
>> closest to the one requested is the one selected, though the current
>> parent is used by default.
>>
>> Signed-off-by: Alex Elder
>> ---
>> This patch is based on Mike Turquette's current "clk-next" branch.
>> 6ed8eb5 Merge tag 'clk-hisi-for-v3.16' of https://git.kern...
>>
>> It is available here:
>> http://git.linaro.org/landing-teams/working/broadcom/kernel.git
>> Branch review/bcm-determine-rate
>>
>> drivers/clk/bcm/clk-kona.c | 53
>> +-
>> 1 file changed, 52 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/bcm/clk-kona.c b/drivers/clk/bcm/clk-kona.c
>> index d603c4e..1a4eccc 100644
>> --- a/drivers/clk/bcm/clk-kona.c
>> +++ b/drivers/clk/bcm/clk-kona.c
>> @@ -1031,6 +1031,57 @@ static long kona_peri_clk_round_rate(struct clk_hw
>> *hw, unsigned long rate,
>> rate ? rate : 1, *parent_rate, NULL);
>> }
>>
>> +static long kona_peri_clk_determine_rate(struct clk_hw *hw, unsigned long
>> rate,
>> + unsigned long *best_parent_rate, struct clk **best_parent)
>> +{
>> + struct kona_clk *bcm_clk = to_kona_clk(hw);
>> + struct clk *clk = hw->clk;
>> + struct clk *current_parent;
>> + unsigned long parent_rate;
>> + unsigned long best_delta;
>> + unsigned long best_rate;
>> + u32 parent_count;
>> + u32 which;
>> +
>> + /*
>> +* If there is no other parent to choose, use the current one.
>> +* Note: We don't honor (or use) CLK_SET_RATE_NO_REPARENT.
>> +*/
>
> A WARN_ONCE is appropriate upon detection of CLK_SET_RATE_NO_REPARENT.
> It will certainly help someone that is debugging why that flag has no
> effect.
I'll add that.
> Otherwise the patch looks good to me.
Would you like me to send an updated patch as a pull request?
Thanks.
-Alex
> Regards,
> Mike
>
>> + parent_count = (u32)bcm_clk->init_data.num_parents;
>> + if (parent_count < 2)
>> + return kona_peri_clk_round_rate(hw, rate, best_parent_rate);
>> +
>> + /* Unless we can do better, stick with current parent */
>> + current_parent = clk_get_parent(clk);
>> + parent_rate = __clk_get_rate(current_parent);
>> + best_rate = kona_peri_clk_round_rate(hw, rate, _rate);
>> + best_delta = abs(best_rate - rate);
>> +
>> + /* Check whether any other parent clock can produce a better result
>> */
>> + for (which = 0; which < parent_count; which++) {
>> + struct clk *parent = clk_get_parent_by_index(clk, which);
>> + unsigned long delta;
>> + unsigned long other_rate;
>> +
>> + BUG_ON(!parent);
>> + if (parent == current_parent)
>> + continue;
>> +
>> + /* We don't support CLK_SET_RATE_PARENT */
>> + parent_rate = __clk_get_rate(parent);
>> + other_rate = kona_peri_clk_round_rate(hw, rate,
>> _rate);
>> + delta = abs(other_rate - rate);
>> + if (delta < best_delta) {
>> + best_delta = delta;
>> + best_rate = other_rate;
>> + *best_parent = parent;
>> + *best_parent_rate = parent_rate;
>> + }
>> + }
>> +
>> + return best_rate;
>> +}
>> +
>> static int kona_peri_clk_set_parent(struct clk_hw *hw, u8 index)
>> {
>> struct kona_clk *bcm_clk = to_kona_clk(hw);
>> @@ -1135,7 +1186,7 @@ struct clk_ops kona_peri_clk_ops = {
>> .disable = kona_peri_clk_disable,
>> .is_enabled = kona_peri_clk_is_enabled,
>> .recalc_rate = kona_peri_clk_recalc_rate,
>> - .round_rate = kona_peri_clk_round_rate,
>> + .determine_rate = kona_peri_clk_determine_rate,
>> .set_parent = kona_peri_clk_set_parent,
>> .get_parent = kona_peri_clk_get_parent,
>> .set_rate = kona_peri_clk_set_rate,
>> --
>> 1.9.1
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: bcm/kona: implement determine_rate()
Quoting Alex Elder (2014-05-20 06:24:57)
> Implement the clk->determine_rate method for Broadcom Kona peripheral
> clocks. This allows a peripheral clock to be re-parented in order to
> satisfy a rate change request. This takes the place of the previous
> kona_peri_clk_round_rate() functionality, though that function remains
> because it is used by the new one.
>
> The parent clock that allows the peripheral clock to produce a rate
> closest to the one requested is the one selected, though the current
> parent is used by default.
>
> Signed-off-by: Alex Elder
> ---
> This patch is based on Mike Turquette's current "clk-next" branch.
> 6ed8eb5 Merge tag 'clk-hisi-for-v3.16' of https://git.kern...
>
> It is available here:
> http://git.linaro.org/landing-teams/working/broadcom/kernel.git
> Branch review/bcm-determine-rate
>
> drivers/clk/bcm/clk-kona.c | 53
> +-
> 1 file changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/bcm/clk-kona.c b/drivers/clk/bcm/clk-kona.c
> index d603c4e..1a4eccc 100644
> --- a/drivers/clk/bcm/clk-kona.c
> +++ b/drivers/clk/bcm/clk-kona.c
> @@ -1031,6 +1031,57 @@ static long kona_peri_clk_round_rate(struct clk_hw
> *hw, unsigned long rate,
> rate ? rate : 1, *parent_rate, NULL);
> }
>
> +static long kona_peri_clk_determine_rate(struct clk_hw *hw, unsigned long
> rate,
> + unsigned long *best_parent_rate, struct clk **best_parent)
> +{
> + struct kona_clk *bcm_clk = to_kona_clk(hw);
> + struct clk *clk = hw->clk;
> + struct clk *current_parent;
> + unsigned long parent_rate;
> + unsigned long best_delta;
> + unsigned long best_rate;
> + u32 parent_count;
> + u32 which;
> +
> + /*
> +* If there is no other parent to choose, use the current one.
> +* Note: We don't honor (or use) CLK_SET_RATE_NO_REPARENT.
> +*/
A WARN_ONCE is appropriate upon detection of CLK_SET_RATE_NO_REPARENT.
It will certainly help someone that is debugging why that flag has no
effect.
Otherwise the patch looks good to me.
Regards,
Mike
> + parent_count = (u32)bcm_clk->init_data.num_parents;
> + if (parent_count < 2)
> + return kona_peri_clk_round_rate(hw, rate, best_parent_rate);
> +
> + /* Unless we can do better, stick with current parent */
> + current_parent = clk_get_parent(clk);
> + parent_rate = __clk_get_rate(current_parent);
> + best_rate = kona_peri_clk_round_rate(hw, rate, _rate);
> + best_delta = abs(best_rate - rate);
> +
> + /* Check whether any other parent clock can produce a better result */
> + for (which = 0; which < parent_count; which++) {
> + struct clk *parent = clk_get_parent_by_index(clk, which);
> + unsigned long delta;
> + unsigned long other_rate;
> +
> + BUG_ON(!parent);
> + if (parent == current_parent)
> + continue;
> +
> + /* We don't support CLK_SET_RATE_PARENT */
> + parent_rate = __clk_get_rate(parent);
> + other_rate = kona_peri_clk_round_rate(hw, rate, _rate);
> + delta = abs(other_rate - rate);
> + if (delta < best_delta) {
> + best_delta = delta;
> + best_rate = other_rate;
> + *best_parent = parent;
> + *best_parent_rate = parent_rate;
> + }
> + }
> +
> + return best_rate;
> +}
> +
> static int kona_peri_clk_set_parent(struct clk_hw *hw, u8 index)
> {
> struct kona_clk *bcm_clk = to_kona_clk(hw);
> @@ -1135,7 +1186,7 @@ struct clk_ops kona_peri_clk_ops = {
> .disable = kona_peri_clk_disable,
> .is_enabled = kona_peri_clk_is_enabled,
> .recalc_rate = kona_peri_clk_recalc_rate,
> - .round_rate = kona_peri_clk_round_rate,
> + .determine_rate = kona_peri_clk_determine_rate,
> .set_parent = kona_peri_clk_set_parent,
> .get_parent = kona_peri_clk_get_parent,
> .set_rate = kona_peri_clk_set_rate,
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[no subject]
Good day, We are Christian organization, we offer loan to those who are in need, contact us via email, marieloanlend...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
Good day, We are Christian organization, we offer loan to those who are in need, contact us via email, marieloanlend...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v2 0/3] bus: add Broadcom GISB bus arbiter timeout/error handler
On Monday 19 May 2014, Florian Fainelli wrote: > Hi all, > > This patch adds support for the Broadcom GISB bus arbiter timeout/error > handler. > GISB is a custom and proprietary bus used in the Broadcom Set Top Box devices > exclusively. The bus arbiter offers the possibly to decode faulting masters as > well as masters that are timing out on the bus. > > V2 addresses some comments made by Arnd, and widens the audience by posting > on linux-arm-kernel as well. > > These patches should be merged via the 'arm-soc' tree. I am resending those > such that every mailing-list has them in copy. > > Thank you! Applied to the next/drivers branch now. I've changed the Kconfig and Makefile slightly to maintain alphabetical ordering, which helps avoid a merge conflict with the vexpress drivers. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: qcom: Fix blsp2_ahb_clk register offset
Quoting Georgi Djakov (2014-05-20 09:50:54)
> The address of the blsp2_ahb_clk register is incorrect. Fix it.
>
> Signed-off-by: Georgi Djakov
Applied to clk-next.
Regards,
Mike
> ---
> drivers/clk/qcom/gcc-msm8974.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/qcom/gcc-msm8974.c b/drivers/clk/qcom/gcc-msm8974.c
> index 51d457e..7968ed2 100644
> --- a/drivers/clk/qcom/gcc-msm8974.c
> +++ b/drivers/clk/qcom/gcc-msm8974.c
> @@ -1340,7 +1340,7 @@ static struct clk_branch gcc_blsp1_uart6_apps_clk = {
> };
>
> static struct clk_branch gcc_blsp2_ahb_clk = {
> - .halt_reg = 0x05c4,
> + .halt_reg = 0x0944,
> .halt_check = BRANCH_HALT_VOTED,
> .clkr = {
> .enable_reg = 0x1484,
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC
On 24.05.2014 00:48, Tarek Dakhran wrote: > Sorry, only now catch it! > I agree, this patch is not needed anymore, except Kconfig option. > config SOC_EXYNOS5410 is needed to build clock stuff. Right, I missed this. > What is your opinion, Tomasz? > I'd suggest re-spinning this series once more, removing changes that are not needed anymore, but keeping the Kconfig entry. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: Silicom: Bypasslib: Fixed a couple of checkpatch.pl warnings
On Fri, May 23, 2014 at 02:39:43PM -0700, Chaitanya Hazarey wrote:
> Added a blank line after declarations to fix the following warnings issued by
> checkpatch.pl:
>
> drivers/staging/silicom/bypasslib/bypass.c:138: WARNING: Missing a blank line
> after declarations
> drivers/staging/silicom/bypasslib/bypass.c:189: WARNING: Missing a blank line
> after declarations
>
> Signed-off-by: Chaitanya Hazarey
Still doesn't apply, I'm afraid.
> ---
> drivers/staging/silicom/bypasslib/bypass.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/staging/silicom/bypasslib/bypass.c
> b/drivers/staging/silicom/bypasslib/bypass.c
> index a58251f..8e714a8 100644
> --- a/drivers/staging/silicom/bypasslib/bypass.c
> +++ b/drivers/staging/silicom/bypasslib/bypass.c
> @@ -135,6 +135,7 @@ static int doit(int cmd, int if_index, int *data)
> static int is_dev_sd(int if_index)
> {
> int ret = 0;
> +
> SET_BPLIB_INT_FN(is_bypass, int, if_index, ret);
> return ret >= 0 ? 1 : 0;
> }
> @@ -186,6 +187,7 @@ static int is_bypass_dev(int if_index)
> static int is_bypass(int if_index)
> {
> int ret = 0;
> +
> SET_BPLIB_INT_FN(is_bypass, int, if_index, ret);
> if (ret < 0)
There was supposed to be a blank line between the call to
SET_BPLIB_INT_FN() and the return check and it got deleted for some
reason.
regards,
dan carpetner
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 2/3] clk: exynos5410: register clocks using common clock framework
This is just my inattention. Will be corrected until Monday. On Sat, May 24, 2014 at 1:19 AM, Tomasz Figa wrote: > Hi Tarek, > > Thanks for keeping up with addressing my comments. See below. > > On 23.05.2014 12:35, Tarek Dakhran wrote: >> The EXYNOS5410 clocks are statically listed and registered >> using the Samsung specific common clock helper functions. >> >> Signed-off-by: Tarek Dakhran >> Signed-off-by: Vyacheslav Tyrtov >> --- >> .../devicetree/bindings/clock/exynos5410-clock.txt | 51 + >> drivers/clk/samsung/Makefile |1 + >> drivers/clk/samsung/clk-exynos5410.c | 209 >> >> include/dt-bindings/clock/exynos5410.h | 33 >> 4 files changed, 294 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/clock/exynos5410-clock.txt >> create mode 100644 drivers/clk/samsung/clk-exynos5410.c >> create mode 100644 include/dt-bindings/clock/exynos5410.h >> > > The driver itself looks good, but binding documentation seems to be > outdated. The part about external clocks, more specifically. > >> diff --git a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt >> b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt >> new file mode 100644 >> index 000..82337c4 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt >> @@ -0,0 +1,51 @@ >> +* Samsung Exynos5410 Clock Controller >> + >> +The Exynos5410 clock controller generates and supplies clock to various >> +controllers within the Exynos5410 SoC. >> + >> +Required Properties: >> + >> +- compatible: should be "samsung,exynos5410-clock" >> + >> +- reg: physical base address of the controller and length of memory mapped >> + region. >> + >> +- #clock-cells: should be 1. >> + >> +All available clocks are defined as preprocessor macros in >> +dt-bindings/clock/exynos5410.h header and can be used in device >> +tree sources. >> + >> +External clock: >> +There is clock that is generated outside the SoC. It is expected >> +that it is defined using standard clock bindings with following >> + - compatible: should be "samsung,exynos5410-oscclk" > > ^ Best regards, Tarek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/3] clk: s2mps11: Fixes and add support for S2MPS14 clocks
Quoting Krzysztof Kozlowski (2014-05-21 04:22:58) > Hi, > > > This is actually a resend of previous patches, rebased on latest > 3.15-rc5. There are no changes, beside rebasing. > > The first two fixes were posted previously as separate patches and they > didn't get review [1]. I am attaching them here. > The last patch adds support for S2MPS14 device and already was > reviewed/acked [2]. > > Mike, could you pick them up or should they go through MFD tree? Applied to clk-next. Regards, Mike > > > [1] https://lkml.org/lkml/2014/4/7/42 > [2] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/28039/focus=310279 > > > Changes since v3: > = > 1. Add Mike's acked-by (see [2]). > 2. Rebase patch 3/3 on the fixes (patches 1 and 2). > 3. Rebase on v3.15-rc5-157-g60b5f90d0fac > > Changes since v2: > = > 1. Patch 2/3: Remove MFD cells of_compatible which aren't used by child >drivers and are not documented. > 2. Added Tomasz's Review-by. > > Changes since v1: > = > 1. Patch 1/3: Update driver description in Kconfig. > 2. Patch 2/3: Add of_compatible to all MFD cells. > 3. Add Yadwinder's Review-by. > > > Best regards, > Krzysztof > > > Krzysztof Kozlowski (3): > clk: s2mps11: Add missing of_node_put and of_clk_del_provider > clk: s2mps11: Remove useless check for clk_table > clk: s2mps11: Add support for S2MPS14 clocks > > drivers/clk/Kconfig | 8 ++--- > drivers/clk/clk-s2mps11.c | 88 > +-- > 2 files changed, 66 insertions(+), 30 deletions(-) > > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] qcom driver changes for v3.16
On Friday 23 May 2014, Kumar Gala wrote: > The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5: > >Linux 3.15-rc1 (2014-04-13 14:18:35 -0700) > > are available in the git repository at: > >git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git > tags/qcom-drivers-for-3.16 > > for you to fetch changes up to 5d144e36b7c51612922fa05d37ff3a869261cc82: > >soc: qcom: Add GSBI driver (2014-05-23 11:38:04 -0500) > > > Qualcomm ARM Based driver Updates for v3.16 > > * Introduce drivers/soc directory for misc SoC specific code > * Add driver to configure GSBI device Merged into next/drivers, thanks Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC
Sorry, only now catch it! I agree, this patch is not needed anymore, except Kconfig option. config SOC_EXYNOS5410 is needed to build clock stuff. What is your opinion, Tomasz? On Sat, May 24, 2014 at 2:44 AM, Tarek Dakhran wrote: > Hi Tomazs, > > On Sat, May 24, 2014 at 1:11 AM, Tomasz Figa wrote: >> Hi Tarek, >> >> With v2 of the series I mentioned in review of previous version [1], >> this patch can be skipped. >> >> [1] http://www.spinics.net/lists/linux-samsung-soc/msg31258.html >> >> Best regards, >> Tomasz >> >> On 23.05.2014 12:35, Tarek Dakhran wrote: > [snip] >>> diff --git a/arch/arm/mach-exynos/firmware.c >>> b/arch/arm/mach-exynos/firmware.c >>> index 739bdc8..971baf0 100644 >>> --- a/arch/arm/mach-exynos/firmware.c >>> +++ b/arch/arm/mach-exynos/firmware.c >>> @@ -50,7 +50,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned >>> long boot_addr) >>> >>> boot_reg = sysram_ns_base_addr + 0x1c; >>> >>> - if (!soc_is_exynos4212()) >>> + if (!soc_is_exynos4212() && !soc_is_exynos5410()) >>> boot_reg += 4*cpu; >>> >>> __raw_writel(boot_addr, boot_reg); >>> > > I need to define SoC type to set correct bootreg in firmware, > otherwise only one cpu can be booted. > So, this stuff is needed. > > Best regards, > Tarek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC
On 24.05.2014 00:44, Tarek Dakhran wrote: > Hi Tomazs, > > On Sat, May 24, 2014 at 1:11 AM, Tomasz Figa wrote: >> Hi Tarek, >> >> With v2 of the series I mentioned in review of previous version [1], >> this patch can be skipped. >> >> [1] http://www.spinics.net/lists/linux-samsung-soc/msg31258.html >> >> Best regards, >> Tomasz >> >> On 23.05.2014 12:35, Tarek Dakhran wrote: > [snip] >>> diff --git a/arch/arm/mach-exynos/firmware.c >>> b/arch/arm/mach-exynos/firmware.c >>> index 739bdc8..971baf0 100644 >>> --- a/arch/arm/mach-exynos/firmware.c >>> +++ b/arch/arm/mach-exynos/firmware.c >>> @@ -50,7 +50,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned >>> long boot_addr) >>> >>> boot_reg = sysram_ns_base_addr + 0x1c; >>> >>> - if (!soc_is_exynos4212()) >>> + if (!soc_is_exynos4212() && !soc_is_exynos5410()) >>> boot_reg += 4*cpu; >>> >>> __raw_writel(boot_addr, boot_reg); >>> > > I need to define SoC type to set correct bootreg in firmware, > otherwise only one cpu can be booted. > So, this stuff is needed. The patch I referred to in my previous reply changes this condition from !soc_is_exynos4212() to soc_is_exynos4412(), which makes the 4*cpu offset being added only in case of Exynos4412 (and so not being added for Exynos5410). What else is needed? Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC
Hi Tomazs, On Sat, May 24, 2014 at 1:11 AM, Tomasz Figa wrote: > Hi Tarek, > > With v2 of the series I mentioned in review of previous version [1], > this patch can be skipped. > > [1] http://www.spinics.net/lists/linux-samsung-soc/msg31258.html > > Best regards, > Tomasz > > On 23.05.2014 12:35, Tarek Dakhran wrote: [snip] >> diff --git a/arch/arm/mach-exynos/firmware.c >> b/arch/arm/mach-exynos/firmware.c >> index 739bdc8..971baf0 100644 >> --- a/arch/arm/mach-exynos/firmware.c >> +++ b/arch/arm/mach-exynos/firmware.c >> @@ -50,7 +50,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long >> boot_addr) >> >> boot_reg = sysram_ns_base_addr + 0x1c; >> >> - if (!soc_is_exynos4212()) >> + if (!soc_is_exynos4212() && !soc_is_exynos5410()) >> boot_reg += 4*cpu; >> >> __raw_writel(boot_addr, boot_reg); >> I need to define SoC type to set correct bootreg in firmware, otherwise only one cpu can be booted. So, this stuff is needed. Best regards, Tarek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] x86/mce: Distirbute the clear operation of mces_seen to Per-CPU rather than only monarch CPU
On Fri, May 23, 2014 at 4:57 AM, Chen Yucong wrote:
> If (mca_cfg.tolerant == 2 || mce_cfg.tolerant == 3), what can you do for
> it?
Maybe we need to look again at the effects of "tolerant" - and maybe
specify what happens at various levels, There are some obvious
silly bits of code (picking one that is my fault):
if (cfg->tolerant < 3) {
if (no_way_out)
mce_panic("Fatal machine check on current
CPU", , msg);
if (worst == MCE_AR_SEVERITY) {
/* schedule action before return to userland */
mce_save_info(m.addr, m.mcgstatus & MCG_STATUS_RIPV);
set_thread_flag(TIF_MCE_NOTIFY);
} else if (kill_it) {
force_sig(SIGBUS, current);
}
}
Why is the MCE_AR_SEVERITY recovery code not even attempted
if tolerant is >=3? That block of code dates back to before there were
any recoverable cases ... so the insane option of just ignoring the error
and hoping that the end result wasn't too bad made some sort of sense
when compared against a machine crash and not getting any answer at
all.
Or one that Andi pointed out years ago (and had a fix in a tree for):
if (order == 1) {
/* CHECKME: Can this race with a parallel hotplug? */
int cpus = num_online_cpus();
/*
* Monarch: Wait for everyone to go through their scanning
* loops.
*/
while (atomic_read(_executing) <= cpus) {
What if some cpus were offline when this machine check arrived?
Our "offline" code doesn't do anything to the h/w to prevent those
cpus from joining in the machine check fun. So we'll see more than
num_online_cpus() processors arrive to process the machine check.
Andi's fix was in the start of do_machine_check() and just had each
cpu that showed up check whether it was listed as "online" by Linux.
If not, it just cleared MCG_STATUS and returned. I didn't apply it
because I thought we needed to be a bit more robust (what if the offline
cpu actually did have a problem? ... we should at least check that
MCG_STATUS.RIPV=1 before rashly returning ... perhaps even more
tests are needed if the cpu had never been online at all).
So I'm happy that you are taking an interest in machine check code.
I think there are places where it can be made a lot better. I don't
think that moving where mces_seen gets cleared is one of those
places.
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 41/49] media: davinci: vpif_capture: drop unneeded module params
Em Fri, 16 May 2014 19:03:47 +0530
"Lad, Prabhakar" escreveu:
> From: "Lad, Prabhakar"
>
> Signed-off-by: Lad, Prabhakar
-ENOPATCHDESCRIPTION
Why to remove those parameters? Please _ALWAYS_ describe your patches.
My crystal ball is malfunctioning today, so I was unable to scry the
reasons for this patch.
Thanks,
Mauro
> ---
> drivers/media/platform/davinci/vpif_capture.c | 54
> +
> drivers/media/platform/davinci/vpif_capture.h | 11 -
> 2 files changed, 1 insertion(+), 64 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpif_capture.c
> b/drivers/media/platform/davinci/vpif_capture.c
> index d452eaf..e967cf7 100644
> --- a/drivers/media/platform/davinci/vpif_capture.c
> +++ b/drivers/media/platform/davinci/vpif_capture.c
> @@ -38,32 +38,10 @@ MODULE_VERSION(VPIF_CAPTURE_VERSION);
> v4l2_dbg(level, debug, _obj.v4l2_dev, fmt, ## arg)
>
> static int debug = 1;
> -static u32 ch0_numbuffers = 3;
> -static u32 ch1_numbuffers = 3;
> -static u32 ch0_bufsize = 1920 * 1080 * 2;
> -static u32 ch1_bufsize = 720 * 576 * 2;
>
> module_param(debug, int, 0644);
> -module_param(ch0_numbuffers, uint, S_IRUGO);
> -module_param(ch1_numbuffers, uint, S_IRUGO);
> -module_param(ch0_bufsize, uint, S_IRUGO);
> -module_param(ch1_bufsize, uint, S_IRUGO);
>
> MODULE_PARM_DESC(debug, "Debug level 0-1");
> -MODULE_PARM_DESC(ch2_numbuffers, "Channel0 buffer count (default:3)");
> -MODULE_PARM_DESC(ch3_numbuffers, "Channel1 buffer count (default:3)");
> -MODULE_PARM_DESC(ch2_bufsize, "Channel0 buffer size (default:1920 x 1080 x
> 2)");
> -MODULE_PARM_DESC(ch3_bufsize, "Channel1 buffer size (default:720 x 576 x
> 2)");
> -
> -static struct vpif_config_params config_params = {
> - .min_numbuffers = 3,
> - .numbuffers[0] = 3,
> - .numbuffers[1] = 3,
> - .min_bufsize[0] = 720 * 480 * 2,
> - .min_bufsize[1] = 720 * 480 * 2,
> - .channel_bufsize[0] = 1920 * 1080 * 2,
> - .channel_bufsize[1] = 720 * 576 * 2,
> -};
>
> #define VPIF_DRIVER_NAME "vpif_capture"
>
> @@ -609,9 +587,6 @@ static void vpif_config_format(struct channel_obj *ch)
> vpif_dbg(2, debug, "vpif_config_format\n");
>
> common->fmt.fmt.pix.field = V4L2_FIELD_ANY;
> - common->fmt.fmt.pix.sizeimage
> - = config_params.channel_bufsize[ch->channel_id];
> -
> if (ch->vpifparams.iface.if_type == VPIF_IF_RAW_BAYER)
> common->fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_SBGGR8;
> else
> @@ -1358,36 +1333,9 @@ static struct v4l2_file_operations vpif_fops = {
> */
> static int initialize_vpif(void)
> {
> - int err = 0, i, j;
> + int err, i, j;
> int free_channel_objects_index;
>
> - /* Default number of buffers should be 3 */
> - if ((ch0_numbuffers > 0) &&
> - (ch0_numbuffers < config_params.min_numbuffers))
> - ch0_numbuffers = config_params.min_numbuffers;
> - if ((ch1_numbuffers > 0) &&
> - (ch1_numbuffers < config_params.min_numbuffers))
> - ch1_numbuffers = config_params.min_numbuffers;
> -
> - /* Set buffer size to min buffers size if it is invalid */
> - if (ch0_bufsize < config_params.min_bufsize[VPIF_CHANNEL0_VIDEO])
> - ch0_bufsize =
> - config_params.min_bufsize[VPIF_CHANNEL0_VIDEO];
> - if (ch1_bufsize < config_params.min_bufsize[VPIF_CHANNEL1_VIDEO])
> - ch1_bufsize =
> - config_params.min_bufsize[VPIF_CHANNEL1_VIDEO];
> -
> - config_params.numbuffers[VPIF_CHANNEL0_VIDEO] = ch0_numbuffers;
> - config_params.numbuffers[VPIF_CHANNEL1_VIDEO] = ch1_numbuffers;
> - if (ch0_numbuffers) {
> - config_params.channel_bufsize[VPIF_CHANNEL0_VIDEO]
> - = ch0_bufsize;
> - }
> - if (ch1_numbuffers) {
> - config_params.channel_bufsize[VPIF_CHANNEL1_VIDEO]
> - = ch1_bufsize;
> - }
> -
> /* Allocate memory for six channel objects */
> for (i = 0; i < VPIF_CAPTURE_MAX_DEVICES; i++) {
> vpif_obj.dev[i] =
> diff --git a/drivers/media/platform/davinci/vpif_capture.h
> b/drivers/media/platform/davinci/vpif_capture.h
> index 4960504..537076a 100644
> --- a/drivers/media/platform/davinci/vpif_capture.h
> +++ b/drivers/media/platform/davinci/vpif_capture.h
> @@ -125,16 +125,5 @@ struct vpif_device {
> struct vpif_capture_config *config;
> };
>
> -struct vpif_config_params {
> - u8 min_numbuffers;
> - u8 numbuffers[VPIF_CAPTURE_NUM_CHANNELS];
> - s8 device_type;
> - u32 min_bufsize[VPIF_CAPTURE_NUM_CHANNELS];
> - u32 channel_bufsize[VPIF_CAPTURE_NUM_CHANNELS];
> - u8 default_device[VPIF_CAPTURE_NUM_CHANNELS];
> - u32 video_limit[VPIF_CAPTURE_NUM_CHANNELS];
> - u8 max_device_type;
> -};
> -
> #endif /* End of __KERNEL__ */
> #endif /* VPIF_CAPTURE_H */
--
To unsubscribe from this list: send
Re: [PATCH] Staging: Silicom: bpctl_mod.c: Fixed a lot of checkpatch.pl warnings
On Fri, May 23, 2014 at 02:47:10PM -0700, Chaitanya Hazarey wrote: > Added a blank line after declarations in many places to fix the following > warning issued by checkpatch.pl: > > WARNING: Missing a blank line after declarations > --- > drivers/staging/silicom/bpctl_mod.c | 90 > ++- > 1 file changed, 88 insertions(+), 2 deletions(-) Something is corrupted in this patch and it doesn't apply properly. Can you resend it to yourself and try to figure out what went wrong? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: Silicom: Bypasslib: Fixed a couple of checkpatch.pl warnings
On Fri, May 23, 2014 at 02:39:43PM -0700, Chaitanya Hazarey wrote: > Added a blank line after declarations to fix the following warnings issued by > checkpatch.pl: > > drivers/staging/silicom/bypasslib/bypass.c:138: WARNING: Missing a blank line > after declarations > drivers/staging/silicom/bypasslib/bypass.c:189: WARNING: Missing a blank line > after declarations > > Signed-off-by: Chaitanya Hazarey > --- > drivers/staging/silicom/bypasslib/bypass.c |2 ++ > 1 file changed, 2 insertions(+) This patch doesn't apply cleanly. Can you please refresh it against my staging-next branch of staging.git on git.kernel.org and resend? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
Serge Hallyn writes: > Quoting Eric W. Biederman (ebied...@xmission.com): >> >> >> >> Ultimately the technical challenge is how do we create a block device >> >> that is safe for a user who does not have any capabilities to use, and >> >> what can we do with that block device to make it useful. >> > >> > Yes, and I'd like to get started solving those challenges. But I also >> > don't think we can address these two points (support partition blkdevs, >> > help prevent more priveleged users from using a namespace's loop >> > devices) sufficiently while having an implementation completely >> > contained within the loop driver as Greg is requesting. >> >> My key take away from the conversation is that we should reduce the >> scope of what is being done to something that makes sense and the >> propblems are immediately visible. >> >> Part of me would like to suggest that fuse and it's ability to imitate >> device nodes might be a more appropriate solution, to something that > > Do you have a link to more info on this? Some googling got me to an > interesting but old thread on CUSE, but nothing specifically about fuse > doing this. CUSE is probably what I was thinking of. It is all part of the fuse code base in the kernel. And now that I am reminded it is called CUSE I go Duh that is a character device... Fuse and everything it can do is definitely the filesystem I would like to see most have the audits to be enabled in user namespace. Fuse was built to be sufficiently paranoid to allow this and so it should not take a lot to take fuse the rest of the way. >> just needs block device access and nothing else. >> >> For purposes of discussion let's call it unprivloopfs. That can reuse >> code from the loop device or not as appropriate. Not supporting >> paritioning I think is a very reasonable first step until it is shown >> that we can make good use of partitioning support, and there are not >> better ways of solving the problem. >> >> I expect the most productive thing to talk about is what is your >> immediate goal? Mounting a filesystem? Building an iso? > > For me it would be taking an iso and making some changes to it to > localize it (i.e. take an install iso and add preseed file). > > Now of course in the end there is no reason why we can't do all of > this with a new suite of libraries which simply uses read/write with > knowledge of the fs layouts to parse and modify the backing files. > My concern there is that duplicating all of the fs code seems unlikely > to improve the soundness of either implementation. Perhaps we can > autogenerate this from the kernel source? Does fuse already do > something like that? I am not aware of that. But I have not worked extensively with fuse. I do agree that finding a way to perform a read-only mount of an ISO by an unprivielged user is a very interesting use case. Given it's interchange medium nature isofs should be as hardened as human possible, and that is likely easier with a read-only filesystem. And at less than 4000 lines of code isofs is auditable. So as a target for unprivileged mounts of a block device isofs looks like a good place to start. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] clk: flatten clk tree in debugfs
On 05/23/2014 03:59 AM, Peter De Schrijver wrote:
This patch flattens the clk tree in CCF debugfs. Instead of representing the
clocks and their hierarchy as a directory structure under
/sys/kernel/debug/clk, each clock gets a single directory directly under
/sys/kernel/debug/clk.
While this may seem strange, here's way I think this is the right thing to do:
1) a directory structure cannot be 'snapshotted' atomically, therefore it's
not in general possible to get a consistent view of the clocktree, because
clocks can be reparented at any time. This was solved by adding clk_dump
and clk_summary, which do guarantee an atomic snapshot of the tree.
Therefore I think the directory structure doesn't add any value.
2) When writing userspace programs which use the files in the clock
directories (eg. for testing purposes), it's impossible to know for sure
where a certain clock will be, because it might have been reparented by the
time you figured out the path from clk_dump. This makes writing such
programs more difficult than it should be.
So because the directory structure doesn't give any information we don't
already provide by other means and it makes certain usecases more difficult
than the should be, I think we should move to a flat directory containing
one subdir per clock.
Completely agree and a huge ACK to this idea.
Signed-off-by: Peter De Schrijver
---
drivers/clk/clk.c | 54 +++-
1 files changed, 4 insertions(+), 50 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index dff0373..53c6b4f 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -306,7 +306,7 @@ static int clk_debug_create_subtree(struct clk *clk, struct
dentry *pdentry)
goto out;
hlist_for_each_entry(child, >children, child_node)
- clk_debug_create_subtree(child, clk->dentry);
+ clk_debug_create_subtree(child, pdentry);
ret = 0;
out:
@@ -326,29 +326,20 @@ out:
*/
static int clk_debug_register(struct clk *clk)
{
- struct clk *parent;
struct dentry *pdentry;
int ret = 0;
if (!inited)
goto out;
- parent = clk->parent;
-
/*
* Check to see if a clk is a root clk. Also check that it is
* safe to add this clk to debugfs
*/
- if (!parent)
- if (clk->flags & CLK_IS_ROOT)
- pdentry = rootdir;
- else
- pdentry = orphandir;
+ if (clk->flags & CLK_IS_ROOT)
+ pdentry = rootdir;
else
- if (parent->dentry)
- pdentry = parent->dentry;
- else
- goto out;
+ pdentry = orphandir;
I'm confused by this code. Shouldn't pdentry always be the same? Do we
need a dir for orphans? Also, I'm not sure the code is actually right?
Looks like you are putting everything but the root into orphandir?
ret = clk_debug_create_subtree(clk, pdentry);
@@ -372,39 +363,6 @@ static void clk_debug_unregister(struct clk *clk)
}
/**
- * clk_debug_reparent - reparent clk node in the debugfs clk tree
- * @clk: the clk being reparented
- * @new_parent: the new clk parent, may be NULL
- *
- * Rename clk entry in the debugfs clk tree if debugfs has been
- * initialized. Otherwise it bails out early since the debugfs clk tree
- * will be created lazily by clk_debug_init as part of a late_initcall.
- *
- * Caller must hold prepare_lock.
- */
-static void clk_debug_reparent(struct clk *clk, struct clk *new_parent)
-{
- struct dentry *d;
- struct dentry *new_parent_d;
-
- if (!inited)
- return;
-
- if (new_parent)
- new_parent_d = new_parent->dentry;
- else
- new_parent_d = orphandir;
-
- d = debugfs_rename(clk->dentry->d_parent, clk->dentry,
- new_parent_d, clk->name);
- if (d)
- clk->dentry = d;
- else
- pr_debug("%s: failed to rename debugfs entry for %s\n",
- __func__, clk->name);
-}
-
-/**
* clk_debug_init - lazily create the debugfs clk tree visualization
*
* clks are often initialized very early during boot before memory can
@@ -1277,9 +1235,6 @@ static void __clk_set_parent_after(struct clk *clk,
struct clk *parent,
clk_disable(old_parent);
__clk_unprepare(old_parent);
}
-
- /* update debugfs with new clk tree topology */
- clk_debug_reparent(clk, parent);
}
static int __clk_set_parent(struct clk *clk, struct clk *parent, u8 p_index)
@@ -1685,7 +1640,6 @@ out:
void __clk_reparent(struct clk *clk, struct clk *new_parent)
{
clk_reparent(clk, new_parent);
- clk_debug_reparent(clk, new_parent);
This should also make a lot of set rate/parent calls faster even
[GIT PULL] EFI changes for arm64
Catalin reports that the arm64 EFI changes in tip/arm64/efi are causing boot issues when trying to run on a non-EFI machine. The below fix from Leif skips the EFI code on such machines. The following changes since commit 345c736edd07b657a8c48190baed2719b85d0938: efi/arm64: ignore dtb= when UEFI SecureBoot is enabled (2014-04-30 19:57:06 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git arm64-efi for you to fetch changes up to 74bcc2499291d38b6253f9dbd6af33a19508: arm64: efi: only attempt efi map setup if booting via EFI (2014-05-23 15:29:43 +0100) Leif Lindholm (1): arm64: efi: only attempt efi map setup if booting via EFI arch/arm64/kernel/efi.c | 3 +++ 1 file changed, 3 insertions(+) -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v4 0/8] Add Allwinner A31 USB support
On Fri, May 23, 2014 at 08:33:39PM +0200, Maxime Ripard wrote: > Hi Greg, > > On Wed, May 14, 2014 at 06:05:20PM +0200, Greg Kroah-Hartman wrote: > > On Wed, May 14, 2014 at 02:34:19PM +0200, Maxime Ripard wrote: > > > On Tue, May 13, 2014 at 05:44:14PM +0200, Maxime Ripard wrote: > > > > Hi everyone, > > > > > > > > This patchset adds support for the USB controllers found in the > > > > Allwinner A31. > > > > > > > > While the design is similar to the earlier Allwinner SoCs that are > > > > already supported, a few details here and there change, like the fact > > > > that the PHYs now have one clock per phy, while it used to be only one > > > > for all the PHYs. > > > > > > > > Resent adding Alan Stern's Acked-by and puting Greg KH in the > > > > recipients this time... > > > > > > Applied patches 2, 7 and 8. > > > > Feel free to apply patches 5 and 6 to your tree, as your branch needs > > these, with my: > > > > Acked-by: Greg Kroah-Hartman > > > > Or, if you want me to take them, just let me know and I will. > > It looks like it's still not in your tree (or at least, I haven't > received the usual mail notifications). > > Is this expected? Given that I haven't applied any USB patches in a week or so, yes, it is expected... Give me a week or so to catch up, I've been on the road for a month now, and am finally home. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: slicoss: remove private netdev list
On Fri, May 23, 2014 at 01:11:01PM -0700, David Matlack wrote: > Greg, this is one of the two patches that got dropped. It should apply cleanly > in any order with respect to all my other patches. As my patch queue is now flushed out, what is "this" patch? :) Can you please just resend the two missing patches? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: st: Fix memory leak
Quoting Valentin Ilie (2014-04-22 06:15:54)
> When it fails to allocate div, gate should be free'd before return
>
> Signed-off-by: Valentin Ilie
Taken into clk-fixes.
Regards,
Mike
> ---
> drivers/clk/st/clkgen-pll.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/st/clkgen-pll.c b/drivers/clk/st/clkgen-pll.c
> index bca0a0b..a886702 100644
> --- a/drivers/clk/st/clkgen-pll.c
> +++ b/drivers/clk/st/clkgen-pll.c
> @@ -521,8 +521,10 @@ static struct clk * __init clkgen_odf_register(const
> char *parent_name,
> gate->lock = odf_lock;
>
> div = kzalloc(sizeof(*div), GFP_KERNEL);
> - if (!div)
> + if (!div) {
> + kfree(gate);
> return ERR_PTR(-ENOMEM);
> + }
>
> div->flags = CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO;
> div->reg = reg + pll_data->odf[odf].offset;
> --
> 1.8.3.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] qcom defconfig changes for v3.16
On Friday 23 May 2014, Kumar Gala wrote: > Qualcomm ARM Based defconfig Updates for v3.16 > > * Add a new qcom_defconfig for mach-qcom > * Update msm_defconfig for handling building the old mach-msm Merged into next/defconfig, thanks! Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] at91: DT for 3.16 at91-dt3 #3
On Fri, May 23, 2014 at 2:55 PM, Alexandre Belloni wrote: > On 23/05/2014 at 23:27:51 +0200, Arnd Bergmann wrote : >> On Thursday 22 May 2014, Nicolas Ferre wrote: >> > Another AT91 DT pull-request for 3.16. This one is the conversion of two >> > more >> > SoC to Common Clock Framework (aka CCF). I identified it as a "DT" >> > pull-request >> > but it modifies slightly a couple of files in mach-at91 (use of a >> > configuration >> > option). >> >> Four done, four more to go? Nice progress! >> > > I'm on it ;) I actually have two more almost ready but I will submit the > remaining four for 3.17. I don't think this is urgent enough to rush it > and I'd like to test it enough before we start removing the old clock > implementation and board files. I think we should spend some more time discussing DTS naming instead! (Just kidding, good progress. Agreed, let it go in when it's ready, it's why we do frequent kernel releases) -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] of: mdio: fix compile warning in of_mdiobus_register_phy()
2014-05-23 14:33 GMT-07:00 Christian Engelmayer : > Commit de906af1 (net: phy: make of_set_phy_supported work with genphy driver) > removed the last user of variable 'max_speed' in function > of_mdiobus_register_phy(), leading to compile warning "unused variable > ‘max_speed’ [-Wunused-variable]". Thus remove it. > > Signed-off-by: Christian Engelmayer Acked-by: Florian Fainelli > --- > Compile tested. Applies against branch master in tree > git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git > --- > drivers/of/of_mdio.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c > index b857094..7c6e277 100644 > --- a/drivers/of/of_mdio.c > +++ b/drivers/of/of_mdio.c > @@ -46,7 +46,6 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio, > struct device_node *chi > struct phy_device *phy; > bool is_c45; > int rc; > - u32 max_speed = 0; > u32 phy_id; > > is_c45 = of_device_is_compatible(child, > -- > 1.9.1 > -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Pass on hwpoison maintainership to Naoya Noriguchi
On Fri, May 23, 2014 at 05:45:30PM -0400, Naoya Horiguchi wrote: > On Fri, May 23, 2014 at 02:15:39PM -0700, Andi Kleen wrote: > > From: Andi Kleen > > > > Noriguchi-san has done most of the work on hwpoison in the last years > > and he also does most of the reviewing. So I'm passing on the hwpoison > > maintainership to him. > > Thank you, I'll do my best. > > # Could please do s/Noriguchi/Horiguchi/g :) > # It will make someone's grep fail in the future. Sorry about that. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] at91: DT for 3.16 at91-dt3 #3
On 23/05/2014 at 23:27:51 +0200, Arnd Bergmann wrote : > On Thursday 22 May 2014, Nicolas Ferre wrote: > > Another AT91 DT pull-request for 3.16. This one is the conversion of two > > more > > SoC to Common Clock Framework (aka CCF). I identified it as a "DT" > > pull-request > > but it modifies slightly a couple of files in mach-at91 (use of a > > configuration > > option). > > Four done, four more to go? Nice progress! > I'm on it ;) I actually have two more almost ready but I will submit the remaining four for 3.17. I don't think this is urgent enough to rush it and I'd like to test it enough before we start removing the old clock implementation and board files. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] phy: add support for USB cluster on the Armada 375 SoC
On 23/05/2014 11:20, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Friday 16 May 2014 09:52 PM, Gregory CLEMENT wrote:
>> The Armada 375 SoC comes with an USB2 host and device controller and
>> an USB3 controller. The USB cluster control register allows to manage
>> common features of both USB controllers.
>>
>> This commit adds a driver integrated in the generic PHY framework to
>> control this USB cluster feature.
>>
>> Signed-off-by: Gregory CLEMENT
>> Signed-off-by: Thomas Petazzoni
>> ---
>> drivers/phy/Kconfig | 6 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-armada375-usb2.c | 140
>> +++
>> include/dt-bindings/phy/armada-375-usb-cluster.h | 18 +++
[...]
>> +static struct phy_ops armada375_usb_phy_ops = {
>> +.init = armada375_usb_phy_init,
>> +.owner = THIS_MODULE,
>
> nitpick: unnecessary tab.
OK
>> +};
>> +
>> +/*
>> + * Only one controller can use this PHY. We shouldn't have the case
>> + * when two controllers want to use this PHY. But if this case occurs
>> + * then we provide a phy to the first one and return an error for the
>> + * next one. This error has also to be an error returned by
>> + * devm_phy_optional_get() so different from ENODEV for USB2. In the
>> + * USB3 case it still optional and we use ENODEV.
>> + */
>> +static struct phy *armada375_usb_phy_xlate(struct device *dev,
>> +struct of_phandle_args *args)
>> +{
>> +if (WARN_ON(usb_cluster_phy.phy_provided)) {
>> +dev_err(dev, "This PHY has already been provided!\n");
>> +dev_err(dev, "Check your device tree, only one controller can
>> use it\n.");
>> +if (args->args[0] == PHY_USB2)
>> +return ERR_PTR(-EBUSY);
>> +else
>> +return ERR_PTR(-ENODEV);
>> +}
>> +
>> +if (args->args[0] == PHY_USB2)
>> +usb_cluster_phy.use_usb3 = false;
>> +else if (args->args[0] == PHY_USB3)
>> +usb_cluster_phy.use_usb3 = true;
>> +else {
>> +dev_err(dev, "Invalid PHY mode\n");
>> +return ERR_PTR(-ENODEV);
>> +}
>
> how will this behave if there is a phy_put and then a phy_get?
Badly I think :(
I have to think about a better solution then.
>> +
>> +usb_cluster_phy.phy_provided = true;
>> +
>> +return usb_cluster_phy.phy;
>> +}
>> +
>> +static int armada375_usb_phy_probe(struct platform_device *pdev)
>> +{
>> +struct device *dev = >dev;
>> +struct phy *phy;
>> +struct phy_provider *phy_provider;
>> +void __iomem *usb_cluster_base;
>> +struct resource *res;
>> +
>> +res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +usb_cluster_base = devm_ioremap_resource(>dev, res);
>> +if (!usb_cluster_base)
>> +return -ENOMEM;
>> +
>> +phy = devm_phy_create(dev, _usb_phy_ops, NULL);
>> +if (IS_ERR(phy)) {
>> +dev_err(dev, "failed to create PHY \n");
>> +return PTR_ERR(phy);
>> +}
>> +
>> +usb_cluster_phy.phy = phy;
>> +usb_cluster_phy.reg = usb_cluster_base;
>> +phy_set_drvdata(phy, _cluster_phy);
>> +
>> +phy_provider = devm_of_phy_provider_register(>dev,
>> + armada375_usb_phy_xlate);
>> +if (IS_ERR(phy_provider))
>> +return PTR_ERR(phy_provider);
>> +
>> +return 0;
>> +}
>> +
>> +static const struct of_device_id of_usb_cluster_table[] = {
>> +{ .compatible = "marvell,armada-375-usb-cluster", },
>> +{ /* end of list */ },
>> +};
>> +MODULE_DEVICE_TABLE(of, of_usb_cluster_table);
>> +
>> +static struct platform_driver armada375_usb_phy_driver = {
>> +.probe = armada375_usb_phy_probe,
>> +.driver = {
>> +.of_match_table = of_usb_cluster_table,
>> +.name = "armada-375-usb-cluster",
>> +.owner = THIS_MODULE,
>> +}
>> +};
>> +module_platform_driver(armada375_usb_phy_driver);
>> +
>> +MODULE_DESCRIPTION("Armada 375 USB cluster driver");
>> +MODULE_AUTHOR("Gregory CLEMENT ");
>> +MODULE_LICENSE("GPL");
>
> GPL v2?
See the header, I chose "GNU General Public License version 2 or later."
so "GPL" match it.
Thanks for your review, once I will have found a proper solution for the
phy_put/phy_get scenario, I will sent a new version with all the other issues
fixed.
Gregory
>
> Thanks
> Kishon
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] x86/mce: Distirbute the clear operation of mces_seen to Per-CPU rather than only monarch CPU
On Thu, May 22, 2014 at 6:32 PM, Chen Yucong wrote: > As Naoya Horiguchi says, this patch also have a small benefit that it > can reduce the processing time of monarch CPU. This is indeed a benefit - but I'm not super worried about performance of machine check handler. >/* > * Now clear the mces_seen of current CPU -*final - so that it > does not > * reappear on the next mce. > */ >memset(final, 0, sizeof(struct mce)); >mce_wrmsrl(MSR_IA32_MCG_STATUS, 0); But if the monarch hasn't managed to clean mces_seen, then it certainly hasn't cleared MCG_STATUS ... so there can't be a "next" mce that would see these old values. Any extra MCE will result in system reset. So we are not arguing that your patch is wrong - it just doesn't seem to be any better that what we have now (except for an unimportant small performance improvement). -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/madvise: fix WILLNEED on SHM/ANON to actually do something
Hi
On Fri, May 23, 2014 at 10:55 PM, David Rientjes wrote:
> On Fri, 23 May 2014, David Herrmann wrote:
>
>> diff --git a/mm/madvise.c b/mm/madvise.c
>> index 539eeb9..a402f8f 100644
>> --- a/mm/madvise.c
>> +++ b/mm/madvise.c
>> @@ -195,7 +195,7 @@ static void force_shm_swapin_readahead(struct
>> vm_area_struct *vma,
>> for (; start < end; start += PAGE_SIZE) {
>> index = ((start - vma->vm_start) >> PAGE_SHIFT) +
>> vma->vm_pgoff;
>>
>> - page = find_get_page(mapping, index);
>> + page = find_get_entry(mapping, index);
>> if (!radix_tree_exceptional_entry(page)) {
>> if (page)
>> page_cache_release(page);
>
> This is already in -mm from Johannes, see
> http://marc.info/?l=linux-kernel=139998616712729. Check out
> http://www.ozlabs.org/~akpm/mmotm/ for this kernel.
Didn't check -mm, sorry. Thanks for the links!
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: Silicom: bpctl_mod.c: Fixed a lot of checkpatch.pl warnings
Added a blank line after declarations in many places to fix the following
warning issued by checkpatch.pl:
WARNING: Missing a blank line after declarations
---
drivers/staging/silicom/bpctl_mod.c | 90 ++-
1 file changed, 88 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/silicom/bpctl_mod.c
b/drivers/staging/silicom/bpctl_mod.c
index 7f3d884..f0c6831 100644
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@ -752,6 +752,7 @@ static void write_reg(struct bpctl_dev *pbpctl_dev,
unsigned char value,
uint32_t ctrl_ext = 0, ctrl = 0;
struct bpctl_dev *pbpctl_dev_c = NULL;
unsigned long flags;
+
if (pbpctl_dev->bp_10g9) {
pbpctl_dev_c = get_status_port_fn(pbpctl_dev);
if (!pbpctl_dev_c)
@@ -927,6 +928,7 @@ static int read_reg(struct bpctl_dev *pbpctl_dev, unsigned
char addr)
#ifdef BP_SYNC_FLAG
unsigned long flags;
+
spin_lock_irqsave(_dev->bypass_wr_lock, flags);
#else
atomic_set(_dev->wdt_busy, 1);
@@ -1563,6 +1565,7 @@ int pulse_set_fn(struct bpctl_dev *pbpctl_dev, unsigned
int counter)
int zero_set_fn(struct bpctl_dev *pbpctl_dev)
{
uint32_t ctrl_ext = 0, ctrl_value = 0;
+
if (!pbpctl_dev)
return -1;
@@ -1588,6 +1591,7 @@ int zero_set_fn(struct bpctl_dev *pbpctl_dev)
int pulse_get2_fn(struct bpctl_dev *pbpctl_dev)
{
uint32_t ctrl_ext = 0, ctrl_value = 0;
+
if (!pbpctl_dev)
return -1;
@@ -1603,6 +1607,7 @@ int pulse_get2_fn(struct bpctl_dev *pbpctl_dev)
int pulse_get1_fn(struct bpctl_dev *pbpctl_dev)
{
uint32_t ctrl_ext = 0, ctrl_value = 0;
+
if (!pbpctl_dev)
return -1;
@@ -1666,6 +1671,7 @@ static struct bpctl_dev *lookup_port(struct bpctl_dev
*dev)
{
struct bpctl_dev *p;
int n;
+
for (n = 0, p = bpctl_dev_arr; n < device_num && p->pdev; n++) {
if (p->bus == dev->bus
&& p->slot == dev->slot
@@ -1843,6 +1849,7 @@ static int bypass_off(struct bpctl_dev *pbpctl_dev)
static int tap_off(struct bpctl_dev *pbpctl_dev)
{
int ret = BP_NOT_CAP;
+
if ((pbpctl_dev->bp_caps & TAP_CAP)
&& (pbpctl_dev->bp_ext_ver >= PXG2TBPI_VER)) {
write_data(pbpctl_dev, TAP_OFF);
@@ -1856,6 +1863,7 @@ static int tap_off(struct bpctl_dev *pbpctl_dev)
static int tap_on(struct bpctl_dev *pbpctl_dev)
{
int ret = BP_NOT_CAP;
+
if ((pbpctl_dev->bp_caps & TAP_CAP)
&& (pbpctl_dev->bp_ext_ver >= PXG2TBPI_VER)) {
write_data(pbpctl_dev, TAP_ON);
@@ -1869,6 +1877,7 @@ static int tap_on(struct bpctl_dev *pbpctl_dev)
static int disc_off(struct bpctl_dev *pbpctl_dev)
{
int ret = 0;
+
if ((pbpctl_dev->bp_caps & DISC_CAP) && (pbpctl_dev->bp_ext_ver >=
0x8)) {
write_data(pbpctl_dev, DISC_OFF);
msec_delay_bp(LATCH_DELAY);
@@ -2270,6 +2279,7 @@ static int set_tx(struct bpctl_dev *pbpctl_dev, int
tx_state)
{
int ret = 0, ctrl = 0;
struct bpctl_dev *pbpctl_dev_m;
+
if ((is_bypass_fn(pbpctl_dev)) == 1)
pbpctl_dev_m = pbpctl_dev;
else
@@ -2802,6 +2812,7 @@ int wdt_time_left(struct bpctl_dev *pbpctl_dev)
static int wdt_timer(struct bpctl_dev *pbpctl_dev, int *time_left)
{
int ret = 0;
+
if (pbpctl_dev->bp_caps & WD_CTL_CAP) {
{
if (pbpctl_dev->wdt_status == WDT_STATUS_UNKNOWN)
@@ -3014,6 +3025,7 @@ static int tx_status(struct bpctl_dev *pbpctl_dev)
{
uint32_t ctrl = 0;
struct bpctl_dev *pbpctl_dev_m;
+
if ((is_bypass_fn(pbpctl_dev)) == 1)
pbpctl_dev_m = pbpctl_dev;
else
@@ -3195,6 +3207,7 @@ static int bypass_change_status(struct bpctl_dev
*pbpctl_dev)
static int bypass_status(struct bpctl_dev *pbpctl_dev)
{
u32 ctrl_ext = 0;
+
if (pbpctl_dev->bp_caps & BP_CAP) {
struct bpctl_dev *pbpctl_dev_b = NULL;
@@ -3323,6 +3336,7 @@ static int dis_bypass_cap_status(struct bpctl_dev
*pbpctl_dev)
static int wdt_programmed(struct bpctl_dev *pbpctl_dev, int *timeout)
{
int ret = 0;
+
if (pbpctl_dev->bp_caps & WD_CTL_CAP) {
if (pbpctl_dev->bp_ext_ver >= PXG2BPI_VER) {
if ((read_reg(pbpctl_dev, STATUS_REG_ADDR)) &
@@ -3386,6 +3400,7 @@ static int tap_flag_status(struct bpctl_dev *pbpctl_dev)
static int tap_flag_status_clear(struct bpctl_dev *pbpctl_dev)
{
uint32_t status_reg = 0;
+
if (pbpctl_dev->bp_caps & TAP_STATUS_CAP) {
if (pbpctl_dev->bp_ext_ver >= PXG2TBPI_VER) {
status_reg = read_reg(pbpctl_dev, STATUS_TAP_REG_ADDR);
@@ -3400,6 +3415,7 @@ static int tap_flag_status_clear(struct bpctl_dev
*pbpctl_dev)
static int tap_change_status(struct bpctl_dev *pbpctl_dev)
{
int ret =
Re: [Patch v7 0/7] Introduce keystone reset driver
On 05/24/2014 12:28 AM, Santosh Shilimkar wrote: On Friday 23 May 2014 11:43 AM, Ivan Khoronzhuk wrote: These patches introduce keystone reset driver. The keystone SoC can be rebooted in several ways. By external reset pin, by soft and by watchdogs. This driver allows software reset and reset by one of the watchdogs. Also added opportunity to set soft/hard reset type. Based on linux-next/master v7..v6 power: reset: keystone-reset: introduce keystone reset driver power: reset: add bindings for keystone reset driver ARM: dts: keystone: update reset node to work with reset driver - s/wdt_list/wdt-list/g I dropped patch 3/7 since its already queued up in mfd tree. Rest of the patches with minor commit edits queued for 3.16. Pull request to follow. Regards, Santosh Thanks. -- Regards, Ivan Khoronzhuk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: Silicom: Bypasslib: Fixed a couple of checkpatch.pl warnings
Added a blank line after declarations to fix the following warnings issued by
checkpatch.pl:
drivers/staging/silicom/bypasslib/bypass.c:138: WARNING: Missing a blank line
after declarations
drivers/staging/silicom/bypasslib/bypass.c:189: WARNING: Missing a blank line
after declarations
Signed-off-by: Chaitanya Hazarey
---
drivers/staging/silicom/bypasslib/bypass.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/silicom/bypasslib/bypass.c
b/drivers/staging/silicom/bypasslib/bypass.c
index a58251f..8e714a8 100644
--- a/drivers/staging/silicom/bypasslib/bypass.c
+++ b/drivers/staging/silicom/bypasslib/bypass.c
@@ -135,6 +135,7 @@ static int doit(int cmd, int if_index, int *data)
static int is_dev_sd(int if_index)
{
int ret = 0;
+
SET_BPLIB_INT_FN(is_bypass, int, if_index, ret);
return ret >= 0 ? 1 : 0;
}
@@ -186,6 +187,7 @@ static int is_bypass_dev(int if_index)
static int is_bypass(int if_index)
{
int ret = 0;
+
SET_BPLIB_INT_FN(is_bypass, int, if_index, ret);
if (ret < 0)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] usb: host: xhci-plat: add optional PHY support
On 23/05/2014 11:28, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Friday 16 May 2014 09:52 PM, Gregory CLEMENT wrote:
>> This commit extends the xhci-plat so that it can optionally be passed
>> a reference to a PHY through the Device Tree. It will be useful for
>> the Armada 375 SoCs. If no PHY is provided then the behavior of the
>> driver is unchanged.
>>
>> As for the clock, to achieve this, it adds a 'struct phy *' member in
>> xhci_hcd. While only used for now in xhci-plat, here again, it might
>> be used by other drivers in the future.
>>
>> Signed-off-by: Gregory CLEMENT
>> ---
>> drivers/usb/host/xhci-plat.c | 29 -
>> drivers/usb/host/xhci.h | 2 ++
>> 2 files changed, 30 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>> index 0f5f4c8f5bf6..34239b582621 100644
>> --- a/drivers/usb/host/xhci-plat.c
>> +++ b/drivers/usb/host/xhci-plat.c
>> @@ -15,6 +15,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> @@ -94,6 +95,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>> struct resource *res;
>> struct usb_hcd *hcd;
>> struct clk *clk;
>> +struct phy *phy;
>> int ret;
>> int irq;
>>
>> @@ -160,9 +162,23 @@ static int xhci_plat_probe(struct platform_device *pdev)
>> goto unmap_registers;
>> }
>>
>> +phy = devm_phy_optional_get(>dev, "usb");
>> +if (IS_ERR(phy)) {
>> +ret = PTR_ERR(phy);
>> +goto disable_clk;
>> +} else {
>> +ret = phy_init(phy);
>> +if (ret)
>> +goto disable_phy;
> s
> I think you meant disable_clk here?
yes indeed!
>> +
>> +ret = phy_power_on(phy);
>> +if (ret)
>> +goto disable_phy;
>> +}
>> +
>> ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
>> if (ret)
>> -goto disable_clk;
>> +goto power_off_phy;
>>
>> device_wakeup_enable(hcd->self.controller);
>>
>> @@ -198,6 +214,12 @@ put_usb3_hcd:
>> dealloc_usb2_hcd:
>> usb_remove_hcd(hcd);
>>
>> +power_off_phy:
>> +if (!IS_ERR(phy))
>
> This check is unnecessary here since you do power_off only if PHY is not
> error.
Good catch again!
>> +phy_power_off(phy);
>> +disable_phy:
>> +if (!IS_ERR(phy))
>
> same here..
I agree
>> +phy_exit(phy);
>> disable_clk:
>> if (!IS_ERR(clk))
>> clk_disable_unprepare(clk);
>> @@ -219,6 +241,7 @@ static int xhci_plat_remove(struct platform_device *dev)
>> struct usb_hcd *hcd = platform_get_drvdata(dev);
>> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>> struct clk *clk = xhci->clk;
>> +struct phy *phy = xhci->phy;
>>
>> usb_remove_hcd(xhci->shared_hcd);
>> usb_put_hcd(xhci->shared_hcd);
>> @@ -226,6 +249,10 @@ static int xhci_plat_remove(struct platform_device *dev)
>> usb_remove_hcd(hcd);
>> if (!IS_ERR(clk))
>> clk_disable_unprepare(clk);
>> +if (!IS_ERR(phy)) {
>
> same here..
I agree too
Thanks for you review,
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: divider: Fix table round up function
Quoting Maxime COQUELIN (2014-05-07 09:48:52)
> Commit 1d9fe6b97 ("clk: divider: Fix best div calculation for power-of-two and
> table dividers") introduces a regression in its _table_round_up function.
>
> When the divider passed to this function is greater than the max divider
> available in the table, this function returns table's max divider.
> Problem is that it causes an infinite loop in clk_divider_bestdiv() because
> _next_div() will never return a value greater than maxdiv.
>
> Instead of returning table's max divider, this patch returns INT_MAX.
>
> Reported-by: Fabio Estevam
> Reported-by: Shawn Guo
> Tested-by: Fabio Estevam
> Cc: Mike Turquette
> Signed-off-by: Maxime Coquelin
Pulled into clk-fixes for -rc7.
Regards,
Mike
> ---
> drivers/clk/clk-divider.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index b3c8396..cf9114a 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -158,7 +158,7 @@ static bool _is_valid_div(struct clk_divider *divider,
> unsigned int div)
> static int _round_up_table(const struct clk_div_table *table, int div)
> {
> const struct clk_div_table *clkt;
> - int up = _get_table_maxdiv(table);
> + int up = INT_MAX;
>
> for (clkt = table; clkt->div; clkt++) {
> if (clkt->div == div)
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MIPS: cavium-octeon: remove checks for CONFIG_CAVIUM_GDB
On Thu, May 22, 2014 at 03:26:45PM +0200, Ralf Baechle wrote:
> On Tue, May 20, 2014 at 06:16:14PM +0200, Paul Bolle wrote:
>
> > Three checks for CONFIG_CAVIUM_GDB were added in v2.6.29. But the
> > Kconfig symbol CAVIUM_GDB was never added to the tree. Remove these
> > checks.
> >
> > Also remove the last reference to octeon_get_boot_debug_flag(). There is
> > no definition of that function anyway.
> >
> > Signed-off-by: Paul Bolle
>
> Queued for 3.16. Thanks Paul & Andreas!
>
> > A follow up might be to remove plat_smp_ops.cpus_done. All these
> > callbacks are now (basically) nops.
>
> I'll think about it. The hook is no useful if unused then again now and
> then ordering issues in SMP startup of secondary CPUs are showing up and
> it may be useful to solve those. Maybe something like
>
> void __init smp_cpus_done(unsigned int max_cpus)
> {
> - mp_ops->cpus_done();
> + if (cpus_done)
> + mp_ops->cpus_done();
> }
>
> which would make a NULL cpus_done function pointer safe and allow empty
> definitions
> to be removed.
I'd prefer this solution over complete removal of the hook.
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 3/4] x86/PCI: Stop enabling ECS for AMD CPUs after Fam16h
On 5/23/2014 6:56 AM, Robert Richter wrote: On 22.05.14 20:54:54, Bjorn Helgaas wrote: I'm going to go out on a limb and guess that Windows does not enable ECS, so it probably uses ECAM. Therefore, I suspect Linux's parsing of MCFG is broken in some way, and we probably *could* use ECAM in all these cases I'm seeing. Even if ECS is not enabled the system should be fine anyway, as ECS is only used to enable certain features. For family 10h this was originally the IBS EILVT (extended interrupt local vector table, needed for hw profiling) setup which need to be set by the OS which the BIOS didn't right. This should be fixed now and properly set by the BIOS on 15h+ systems. I don't remember what was added to 16h where ECS was needed, I think there was one (Suravee?). Not sure if this is essential. I am not aware of anything specific in the family16h which require IO_ECS to be enabled. Suravee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] perf, tools: Support handling complete branch stacks as histograms v6
On Mon, May 19, 2014 at 05:21:15PM +0900, Namhyung Kim wrote:
> This is gone with 540476de74c9 ("perf tools: Remove
> symbol_conf.use_callchain check").
The patchkit applies to tip/perf/core.
> > +* Check for overlap into the callchain.
> > +* The return address is one off compared to
> > +* the branch entry. To adjust for this
> > +* assume the calling instruction is not longer
> > +* than 8 bytes.
> > +*/
> > + if (be[i].from < chain->ips[first_call] &&
> > + be[i].from >= chain->ips[first_call] - 8)
> > + first_call++;
>
> It seems that you need to check chain->ips[first_call] is greater than
> PERF_CONTEXT_MAX and use such value as the cpumode...
I don't understand the comment. The only IP that gets resolved is the from/to.
And add_callchain_ip does it own resolution.
Wouldn't make any sense to get it from first_call
>
>
> > + } else
> > + be[i] = branch->entries[branch->nr - i - 1];
> > + }
> > +
> > + nr = remove_loops(be, nr);
> > +
> > + for (i = 0; i < nr; i++) {
> > + err = add_callchain_ip(machine, thread, parent,
> > + root_al,
> > + -1, be[i].to);
> > + if (!err)
> > + err = add_callchain_ip(machine, thread,
> > + parent, root_al,
> > + -1, be[i].from);
>
> ... for here.
>
>
> > + if (err == -EINVAL)
> > + break;
> > + if (err)
> > + return err;
> > + }
> > + chain_nr -= nr;
>
> It seems it could make some callchain nodes being ignored. What if a
> case like small callchains with matches to only 2 nodes in the LBR?
>
> nr = 16, chain_nr = 10 and first_call = 2
The chain_nr variable is just to handle it when the user
specified a max_stack value. nr is always capped to max_stack too.
If lbr size is >= max_stack it will end up being 0 or negative and the
following loop to add normal call stack entries will do nothing.
I think that's the correct behavior.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc: remove checks for CONFIG_BOOK3E_MMU_TLB_STATS
On Fri, 2014-05-23 at 12:12 -0500, Scott Wood wrote: > On Fri, 2014-05-23 at 12:06 +0200, Paul Bolle wrote: > > For what it's worth: I can't reproduce this error with the cross > > compiler now shipped with Fedora 20 (ie, powerpc64-linux-gnu-gcc (GCC) > > 4.8.1 20130717 (Red Hat 4.8.1-5)). It shows a nice and clean > > AS arch/powerpc/mm/tlb_low_64e.o > > > > in the output. > > > > That's v3.15-rc6, with just this patch, and using a .config generated, > > with "make oldconfig", from arch/powerpc/configs/ppc64e_defconfig. > > Hmm, I tried applying again and it was fine. That's a relieve. Thanks, again, for testing! Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] of: mdio: fix compile warning in of_mdiobus_register_phy()
Commit de906af1 (net: phy: make of_set_phy_supported work with genphy driver) removed the last user of variable 'max_speed' in function of_mdiobus_register_phy(), leading to compile warning "unused variable ‘max_speed’ [-Wunused-variable]". Thus remove it. Signed-off-by: Christian Engelmayer --- Compile tested. Applies against branch master in tree git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git --- drivers/of/of_mdio.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c index b857094..7c6e277 100644 --- a/drivers/of/of_mdio.c +++ b/drivers/of/of_mdio.c @@ -46,7 +46,6 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio, struct device_node *chi struct phy_device *phy; bool is_c45; int rc; - u32 max_speed = 0; u32 phy_id; is_c45 = of_device_is_compatible(child, -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] qcom DT changes for v3.16
On Friday 23 May 2014, Kumar Gala wrote: > > > > Qualcomm ARM Based Device Tree Updates for v3.16 > > > > * Added device tree nodes for pinctrl and SDHC for msm8974 SoC/DB8074 board > > * Added binding spec for GSBI configuration node Pulled into next/dt, thanks! Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] at91: DT for 3.16 at91-dt3 #3
On Thursday 22 May 2014, Nicolas Ferre wrote: > Another AT91 DT pull-request for 3.16. This one is the conversion of two more > SoC to Common Clock Framework (aka CCF). I identified it as a "DT" > pull-request > but it modifies slightly a couple of files in mach-at91 (use of a > configuration > option). Four done, four more to go? Nice progress! > This pull-request depends on: > - the fixes that I already sent for 3.15 and that are present in the recent > 3.15-rc6 tag. > - the at91-cleanup tag that you integrated in your arm-soc/next/soc branch. > So, as suggested by Arnd on IRC, I merged both of them to act as the base > before adding the material for this pull-request. > > About the clock nodes that should be grouped in a "clocks" container or not, > while waiting for a clear statement by the DT maintainers, I kept the clocks > nodes as they had been written by Boris. > As proposed by Olof, I plan to send you a comprehensive patch that fixes this > when Mark gives his point of view. Ok. I've merged it into next/dt now. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v7 0/7] Introduce keystone reset driver
On Friday 23 May 2014 11:43 AM, Ivan Khoronzhuk wrote: > These patches introduce keystone reset driver. > > The keystone SoC can be rebooted in several ways. By external reset > pin, by soft and by watchdogs. This driver allows software reset and reset > by one of the watchdogs. Also added opportunity to set soft/hard reset type. > > Based on linux-next/master > > v7..v6 > power: reset: keystone-reset: introduce keystone reset driver > power: reset: add bindings for keystone reset driver > ARM: dts: keystone: update reset node to work with reset driver > - s/wdt_list/wdt-list/g > I dropped patch 3/7 since its already queued up in mfd tree. Rest of the patches with minor commit edits queued for 3.16. Pull request to follow. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab_common: fix the check for duplicate slab names
On 05/23/2014 11:16 PM, Mike Snitzer wrote: On Tue, Mar 25 2014 at 2:07pm -0400, Christoph Lameter wrote: On Tue, 25 Mar 2014, Mike Snitzer wrote: This patch still isn't upstream. Who should be shepherding it to Linus? Pekka usually does that. Acked-by: Christoph Lameter This still hasn't gotten upstream. Pekka, any chance you can pick it up? Here it is in dm-devel's kernel.org patchwork: https://patchwork.kernel.org/patch/3768901/ (Though it looks like it needs to be rebased due to the recent commit 794b1248, should Mikulas rebase and re-send?) I applied it and fixed the conflict by hand. Please double-check commit 694617474e33b8603fc76e090ed7d09376514b1a in my tree: https://git.kernel.org/cgit/linux/kernel/git/penberg/linux.git/ - Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] Documentation: dt-bindings: document the Armada 375 USB cluster binding
On 23/05/2014 15:59, Andrew Lunn wrote: > On Fri, May 23, 2014 at 07:22:48PM +0530, Kishon Vijay Abraham I wrote: >> hI, >> >> On Friday 23 May 2014 07:06 PM, Andrew Lunn wrote: Do you want one .txt file per driver, or can we combine binding documentations into one file? There should already be a mvebu-phy.txt, which contains the sata phy usable on some of the Armada SoC families. This binding could be appended to it. >>> >>> Ah. Humm, well! It seems the patch adding the mvebu-phy.txt fell >>> through a crack when adding the driver. >>> >>> Kishon could you take >>> http://www.spinics.net/lists/devicetree/msg17018.html into your tree? >>> It should of been taken the same time you took the actual driver, >>> http://www.spinics.net/lists/devicetree/msg17011.html into your tree. >>> >>> I can resend that one missing patch if you want. >> >> yes please. But it's already too late to go in the next merge window. > > Gregory, could you pick it up and append your 375 binding to it? We > can avoid merge conflicts that way. yes sure, I will do it > > Thanks > Andrew > -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] of: Make of_find_node_by_path() handle /aliases
On Thu, 22 May 2014 18:14:38 -0700, Frank Rowand wrote:
> On 5/21/2014 6:16 PM, Grant Likely wrote:
> > On Tue, 20 May 2014 19:41:22 -0700, Frank Rowand
> > wrote:
> >> On 5/18/2014 2:27 AM, Grant Likely wrote:
> >>> On Fri, 16 May 2014 11:54:44 +0100, Grant Likely
> >>> wrote:
> On Thu, 15 May 2014 19:51:17 -0700, Frank Rowand
> wrote:
> > On 5/13/2014 7:58 AM, Grant Likely wrote:
> >> Make of_find_node_by_path() handle aliases as prefixes. To make this
> >> work the name search is refactored to search by path component instead
> >> of by full string. This should be a more efficient search, and it makes
> >> it possible to start a search at a subnode of a tree.
> >>
> >> Signed-off-by: David Daney
> >> Signed-off-by: Pantelis Antoniou
> >> [grant.likely: Rework to not require allocating at runtime]
> >> Acked-by: Rob Herring
> >> Signed-off-by: Grant Likely
> >> ---
> >> drivers/of/base.c | 60
> >> +++
> >> 1 file changed, 56 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/of/base.c b/drivers/of/base.c
> >> index 6e240698353b..60089b9a3014 100644
> >> --- a/drivers/of/base.c
> >> +++ b/drivers/of/base.c
> >> @@ -771,9 +771,38 @@ struct device_node *of_get_child_by_name(const
> >> struct device_node *node,
> >> }
> >> EXPORT_SYMBOL(of_get_child_by_name);
> >>
> >> +static struct device_node *__of_find_node_by_path(struct device_node
> >> *parent,
> >> + const char *path)
> >> +{
> >> + struct device_node *child;
> >> + int len = strchrnul(path, '/') - path;
> >> +
> >> + if (!len)
> >> + return parent;
> >
> > (!len) is true if the the final character of the path passed into
> > of_find_node_by_path()
> > was "/". Strictly speaking, ->full_name will never end with "/", so
> > the return value
> > should be NULL, indicating that the match fails.
>
> Ah, good catch. I should add a test case for that.
> >>>
> >>> In my testing this looks okay. The while loop that calls into
> >>> __of_find_node_by_path() looks like this:
> >>>
> >>> while (np && *path == '/') {
> >>> path++; /* Increment past '/' delimiter */
> >>> np = __of_find_node_by_path(np, path);
> >>> path = strchrnul(path, '/');
> >>> }
> >>>
> >>> If the path ends with a '/', then the loop will go around one more time.
> >>> The pointer will be incremented to point at the null character and len
> >>> will be null because strchrnul() will point at the last item.
> >>
> >> Yes, that was my point. The old version of of_find_node_by_path() would
> >> not
> >> find a match if the path ended with a "/" (unless the full path was "/").
> >> This patch series changes the behavior to be a match.
> >>
> >> I will reply to this email with an additional patch that restores the
> >> original behavior.
> >>
> >> If you move the additional test cases you provide below and the test cases
> >> in patch 3 to the beginning of the series, you can see the before and after
> >> behavior of adding patch 1 and patch 2.
> >
> > Ah, I see. That raises the question about what the behaviour /should/
> > be. Off the top of my head, matching against a trailing '/' seems to be
> > okay. Are there situations that you see or can think of where matching
> > would be the wrong thing to do?
>
> I have not thought of a case where matching against a trailing '/' would
> hurt anything. It just seemed better to be consistent in naming.
>
I've gone ahead and merged in the trailing '/' fix. It can be relaxed
later if deemed important.
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 2/3] clk: exynos5410: register clocks using common clock framework
Hi Tarek,
Thanks for keeping up with addressing my comments. See below.
On 23.05.2014 12:35, Tarek Dakhran wrote:
> The EXYNOS5410 clocks are statically listed and registered
> using the Samsung specific common clock helper functions.
>
> Signed-off-by: Tarek Dakhran
> Signed-off-by: Vyacheslav Tyrtov
> ---
> .../devicetree/bindings/clock/exynos5410-clock.txt | 51 +
> drivers/clk/samsung/Makefile |1 +
> drivers/clk/samsung/clk-exynos5410.c | 209
>
> include/dt-bindings/clock/exynos5410.h | 33
> 4 files changed, 294 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/exynos5410-clock.txt
> create mode 100644 drivers/clk/samsung/clk-exynos5410.c
> create mode 100644 include/dt-bindings/clock/exynos5410.h
>
The driver itself looks good, but binding documentation seems to be
outdated. The part about external clocks, more specifically.
> diff --git a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
> b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
> new file mode 100644
> index 000..82337c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
> @@ -0,0 +1,51 @@
> +* Samsung Exynos5410 Clock Controller
> +
> +The Exynos5410 clock controller generates and supplies clock to various
> +controllers within the Exynos5410 SoC.
> +
> +Required Properties:
> +
> +- compatible: should be "samsung,exynos5410-clock"
> +
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +
> +- #clock-cells: should be 1.
> +
> +All available clocks are defined as preprocessor macros in
> +dt-bindings/clock/exynos5410.h header and can be used in device
> +tree sources.
> +
> +External clock:
> +There is clock that is generated outside the SoC. It is expected
> +that it is defined using standard clock bindings with following
> + - compatible: should be "samsung,exynos5410-oscclk"
^
> +
> +Example 1: An example of a clock controller node is listed below.
> +
> + clock: clock-controller@0x1001 {
> + compatible = "samsung,exynos5410-clock";
> + reg = <0x1001 0x3>;
> + #clock-cells = <1>;
> + };
> +
> +Example 2: Required external clock.
> +
> + fixed-rate-clocks {
> + oscclk {
> + compatible = "samsung,exynos5410-oscclk";
> + clock-frequency = <2400>;
> + };
> + };
^
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Pass on hwpoison maintainership to Naoya Noriguchi
From: Andi Kleen Noriguchi-san has done most of the work on hwpoison in the last years and he also does most of the reviewing. So I'm passing on the hwpoison maintainership to him. Cc: Naoya Horiguchi Signed-off-by: Andi Kleen --- MAINTAINERS | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index c596b74..e84d510 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4017,9 +4017,8 @@ S:Odd Fixes F: drivers/media/usb/hdpvr/ HWPOISON MEMORY FAILURE HANDLING -M: Andi Kleen +M: Naoya Horiguchi L: linux...@kvack.org -T: git git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-mce-2.6.git hwpoison S: Maintained F: mm/memory-failure.c F: mm/hwpoison-inject.c -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 3/3] ARM: dts: Add initial device tree support for EXYNOS5410
Hi Tarek, On 23.05.2014 12:35, Tarek Dakhran wrote: > Add initial device tree nodes for EXYNOS5410 SoC and SMDK5410 board. > > Signed-off-by: Tarek Dakhran > Signed-off-by: Vyacheslav Tyrtov > --- > arch/arm/boot/dts/Makefile|1 + > arch/arm/boot/dts/exynos5410-smdk5410.dts | 82 > arch/arm/boot/dts/exynos5410.dtsi | 206 > + > 3 files changed, 289 insertions(+) > create mode 100644 arch/arm/boot/dts/exynos5410-smdk5410.dts > create mode 100644 arch/arm/boot/dts/exynos5410.dtsi Looks good. Hopefully we can have this patch applied soon, so it won't get outdated again. Reviewed-by: Tomasz Figa Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/6] SP800-90A Deterministic Random Bit Generator
Stephan Mueller wrote: > Hi, > > the following set of patches implements the deterministic random bit generator > (DRBG) specified by SP800-90A. > > The DRBG implementation offers the following: > >* All three DRBG types are implemented with a derivation function. >* All DRBG types are available with and without prediction resistance. >* All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available > for the HMAC and Hash DRBGs. >* All AES types of AES-128, AES-192 and AES-256 are available for the > CTR DRBG. >* A self test is implemented with drbg_healthcheck(). >* The FIPS 140-2 continuous self test is implemented. >* Additional cipher primitives, such as Serpent or Twofish, can be > added to the DRBG without changing the implementation. The only > change necessary is to the DRBG definition given in the cores[] > array. Where is the code that actually uses this? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC
Hi Tarek, With v2 of the series I mentioned in review of previous version [1], this patch can be skipped. [1] http://www.spinics.net/lists/linux-samsung-soc/msg31258.html Best regards, Tomasz On 23.05.2014 12:35, Tarek Dakhran wrote: > EXYNOS5410 is SoC in Samsung's Exynos5 SoC series. > Add initial support for this SoC. > > Signed-off-by: Tarek Dakhran > Signed-off-by: Vyacheslav Tyrtov > --- > arch/arm/mach-exynos/Kconfig|8 > arch/arm/mach-exynos/common.h | 11 ++- > arch/arm/mach-exynos/firmware.c |2 +- > 3 files changed, 19 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig > index 1602abc..79a3e85 100644 > --- a/arch/arm/mach-exynos/Kconfig > +++ b/arch/arm/mach-exynos/Kconfig > @@ -84,6 +84,14 @@ config SOC_EXYNOS5250 > help > Enable EXYNOS5250 SoC support > > +config SOC_EXYNOS5410 > + bool "SAMSUNG EXYNOS5410" > + default y > + depends on ARCH_EXYNOS5 > + select PM_GENERIC_DOMAINS if PM_RUNTIME > + help > + Enable EXYNOS5410 SoC support > + > config SOC_EXYNOS5420 > bool "SAMSUNG EXYNOS5420" > default y > diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h > index e2d0954..d64c6de 100644 > --- a/arch/arm/mach-exynos/common.h > +++ b/arch/arm/mach-exynos/common.h > @@ -21,6 +21,7 @@ > #define EXYNOS4_CPU_MASK 0xFFFE > > #define EXYNOS5250_SOC_ID0x4352 > +#define EXYNOS5410_SOC_ID0xE541 > #define EXYNOS5420_SOC_ID0xE542 > #define EXYNOS5440_SOC_ID0xE544 > #define EXYNOS5_SOC_MASK 0xF000 > @@ -37,6 +38,7 @@ IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, > EXYNOS4_CPU_MASK) > IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK) > IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK) > IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID, EXYNOS5_SOC_MASK) > +IS_SAMSUNG_CPU(exynos5410, EXYNOS5410_SOC_ID, EXYNOS5_SOC_MASK) > IS_SAMSUNG_CPU(exynos5420, EXYNOS5420_SOC_ID, EXYNOS5_SOC_MASK) > IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK) > > @@ -68,6 +70,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, > EXYNOS5_SOC_MASK) > # define soc_is_exynos5250() 0 > #endif > > +#if defined(CONFIG_SOC_EXYNOS5410) > +# define soc_is_exynos5410() is_samsung_exynos5410() > +#else > +# define soc_is_exynos5410() 0 > +#endif > + > #if defined(CONFIG_SOC_EXYNOS5420) > # define soc_is_exynos5420() is_samsung_exynos5420() > #else > @@ -82,7 +90,8 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, > EXYNOS5_SOC_MASK) > > #define soc_is_exynos4() (soc_is_exynos4210() || soc_is_exynos4212() || \ > soc_is_exynos4412()) > -#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5420()) > +#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5410() || \ > + soc_is_exynos5420()) > > void mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1); > > diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c > index 739bdc8..971baf0 100644 > --- a/arch/arm/mach-exynos/firmware.c > +++ b/arch/arm/mach-exynos/firmware.c > @@ -50,7 +50,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long > boot_addr) > > boot_reg = sysram_ns_base_addr + 0x1c; > > - if (!soc_is_exynos4212()) > + if (!soc_is_exynos4212() && !soc_is_exynos5410()) > boot_reg += 4*cpu; > > __raw_writel(boot_addr, boot_reg); > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/6] SP800-90A Deterministic Random Bit Generator
Stephan Mueller wrote:
>
> + memset(_algs[i], 0, sizeof(struct crypto_alg));
> + if (pr) {
> + memcpy(drbg_algs[i].cra_name, "drbg(pr(", 8);
> + memcpy(drbg_algs[i].cra_driver_name, "drbg_pr_", 8);
> + pos = 8;
You shouldn't use the brackets here since this not a real template.
Just use one name for both cra_name and cra_driver_name.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] ARM: OMAP5+: Support Duty Cycle Correction(DCC)
Quoting Nishanth Menon (2014-05-16 03:45:57) > Hi, > > This patch series has been carried over in vendor kernel for quiet > few years now. > > Unfortunately, it was very recently re-discovered and upstream kernel > is noticed to be broken for OMAP5 1.5GHz - at least we are operating > DPLL at frequency higher than what it was intended to be when CPUFreq > is enabled. Thankfully, with nominal voltage(we dont use AVS yet in > upstream for the mentioned platforms) and margins in trimming, we > have so far not crashed - but I strongly suspect this might be some > boundary case survival. DCC also exists in OMAP4. In some cases customers used it, in other cases we just ran the PLL way out of spec and the mpu_clk would divide by 2. Is this broken for OMAP4 as well? Regards, Mike > > Verified on the following impacted platforms using 3.15-rc4 based > vendor kernel. > > Before: > OMAP5432: http://slexy.org/view/s20cs0qQFg > DRA72x: http://slexy.org/view/s2TXtSa6mH (refused to lock) > DRA75x: http://slexy.org/view/s20AW8MU5c > After: > OMAP5432: http://slexy.org/view/s21iAfWxpu > DRA72x: http://slexy.org/view/s2hwsvGLmC (locks properly) > DRA75x: http://slexy.org/view/s21ehw8WQn > > Hopefully, we can get these into some kernel revision in some form. > > NOTE: Support for 4470(which is the only other platform requiring > DCC) is not present in upstream kernel and there are no plans to > support that SoC, even if it is added at a later point, support can be > extended as needed. > > Series based on v3.15-rc5 tag. > Also available on my tree: > https://github.com/nmenon/linux-2.6-playground/ > branch: push/clock/dcc > > weblink: > https://github.com/nmenon/linux-2.6-playground/commits/push/clock/dcc > > Verification: > 3.15-rc4 based kernel - DRA75x-evm, 72x-evm, OMAP5uevm > 3.15-rc5 - OMAP5uEVM(only one supporting 1.5GHz atm) > > Andrii Tseglytskyi (1): > ARM: OMAP5+: dpll: support Duty Cycle Correction(DCC) > > Nishanth Menon (2): > clk: dpll: support OMAP5 MPU DPLL that need special handling for > higher frequencies > ARM: dts: OMAP5/DRA7: use omap5-mpu-dpll-clock capable of dealing > with higher frequencies > > .../devicetree/bindings/clock/ti/dpll.txt |1 + > arch/arm/boot/dts/dra7xx-clocks.dtsi |2 +- > arch/arm/boot/dts/omap54xx-clocks.dtsi |2 +- > arch/arm/mach-omap2/dpll3xxx.c |9 + > drivers/clk/ti/dpll.c | 21 > > include/linux/clk/ti.h |4 > 6 files changed, 37 insertions(+), 2 deletions(-) > > Regards, > Nishanth Menon > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
