laina
Hyvää päivää, Olen rouva Rose Butler, toimeenpaneva agentti hyvin tunnustettu laillinen luotonanto yritys tunnetaan YesGrowth Lainat. Onko sinulla huono luotto tai olet tarvitsevat rahaa maksaa laskujaan? meidän korko on 3%. Täytä alla oleva lomake jos kiinnostaa. Koko nimi: sukupuoli: Tarvittava määrä: kesto: Voit ottaa meihin yhteyttä Puh: +447045734550, yesgrowth1...@gmail.com Ystävällisin terveisin, Rouva Rose Butler _ This message is intended only for recipients who are authorized to receive it. It contains confidential and/ or legally privileged information belonging to PT SEMEN INDONESIA (Persero) Tbk, therefore the authorized recipients shall protect this confidential information disclosed pursuant to provisions of Semen Indonesia's policy. If you are not a valid recipient of this message, please delete it from your system and/ or destroy all of the tangible material produced from the information herein together with all copies or reproductions thereof and notify the sender immediately. Please also be notified that any disclosure, copying, distribution or taking any action based on the contents of this message is strictly prohibited and may be unlawful -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: exynos_defconfig: Disable simplefb support
Hello Krzysztof,
On 09/11/2015 07:01 AM, Krzysztof Kozlowski wrote:
> On 10.09.2015 22:42, Javier Martinez Canillas wrote:
>> The simplefb driver allows the kernel to render on a pre-allocated
>> buffer that's been initialized by firmware before the kernel boots.
>>
>> This option was enabled to have display working on the Exynos5250
>> Snow Chromebook by commit da9d0fbf5e9a ("ARM: exynos: defconfig
>> update") since proper DRM/KMS support did not exist at that time.
>>
>> But now that the Exynos DRM driver has support for this hardware,
>> there is no need to have simplefb enabled. In fact, if a user has
>> a u-boot that injects the simplefb dev node to the FDT before pass
>> it to the kernel, display won't be properly initialized and only a
>> blank screen will be shown since there isn't a proper handoff from
>> the simplefb driver to the Exynos DRM driver.
>>
>> Signed-off-by: Javier Martinez Canillas
>>
>> ---
>>
>> arch/arm/configs/exynos_defconfig | 1 -
>> 1 file changed, 1 deletion(-)
>
> Seems logical. None of the boards use simple-framebuffer compatible
> anyway. I understand that on Snow simplefb was needed along with change
> in Uboot like this one:
> https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/refs/changes/58/49358/2
>
Exactly but you won't see the dev node with the "simple-framebuffer"
compatible string in the DTS since is the bootloader that adds this
device node to the FDT before passing it to the kernel.
The bootloader shouldn't mangle the FDT (with the exception of the
memory and choosen/bootargs nodes) but simplefb is just a hack to
re-use the display HW initialization made by the bootloader.
> and now none of Exynos boards use simplefb anymore?
>
Yes, there are no other Exynos boards using simplefb besides Snow
that I'm aware of but since Exynos DRM is working well on this board
from v4.0, there is no need for it anymore.
In fact, as explained in the commit message, it could do more harm
than good since users that are still booting with a u-boot that adds
the simplefb device node, only get a blank screen since the simplefb
driver is probed, creates a console and later the Exynos DRM probes
and re-initializes the HW creating its own console, causing this issue.
I got several reports of users that says that mainline stop booting for
them but is just that they didn't get display working. Disabling simplefb
makes display to work again so maybe this is even -rc material and should
go to stable # v4.0+
> Best regards,
> Krzysztof
>
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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] PM / devfreq: Fix incorrect type issue.
> > > > time_in_state in struct devfreq is defined as unsigned long, so > > devm_kzalloc should use sizeof(unsigned long) as argument instead of > > sizeof(unsigned int), otherwise it will cause unexpected result in > > 64bit system. > > > > Signed-off-by: Xiaolong Ye > > Signed-off-by: Kevin Liu > > Thanks! > > Signed-off-by: MyungJoo Ham > > > Which SoC are you working with? I am working on MARVELL PXA1928 SoC platform(with 4 ARM CA53 cores), and we are using devfreq framework to implement our ddr frequency change design, I found this issue when adapting our driver to 64bit system. > Are you going to upstream your 64bit devfreq driver soon? Currently, we don’t have a plan to upstream our ddr devfreq driver. > > > Cheers, > MyungJoo > > > --- > > drivers/devfreq/devfreq.c |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c > > index ca1b362..ac9845a 100644 > > --- a/drivers/devfreq/devfreq.c > > +++ b/drivers/devfreq/devfreq.c > > @@ -482,7 +482,7 @@ struct devfreq *devfreq_add_device(struct device > *dev, > > devfreq->profile->max_state * > > devfreq->profile->max_state, > > GFP_KERNEL); > > - devfreq->time_in_state = devm_kzalloc(dev, sizeof(unsigned int) * > > + devfreq->time_in_state = devm_kzalloc(dev, sizeof(unsigned long) * > > devfreq->profile->max_state, > > GFP_KERNEL); > > devfreq->last_stat_updated = jiffies; > > -- > > 1.7.9.5
kooperace?
odpovezte mi na nize uvedenou e-mailovou adresu pro vysvetlení výroku. E-mail: chn.j...@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] ARM: exynos_defconfig: Disable simplefb support
On 11.09.2015 16:07, Javier Martinez Canillas wrote:
> Hello Krzysztof,
>
> On 09/11/2015 07:01 AM, Krzysztof Kozlowski wrote:
>> On 10.09.2015 22:42, Javier Martinez Canillas wrote:
>>> The simplefb driver allows the kernel to render on a pre-allocated
>>> buffer that's been initialized by firmware before the kernel boots.
>>>
>>> This option was enabled to have display working on the Exynos5250
>>> Snow Chromebook by commit da9d0fbf5e9a ("ARM: exynos: defconfig
>>> update") since proper DRM/KMS support did not exist at that time.
>>>
>>> But now that the Exynos DRM driver has support for this hardware,
>>> there is no need to have simplefb enabled. In fact, if a user has
>>> a u-boot that injects the simplefb dev node to the FDT before pass
>>> it to the kernel, display won't be properly initialized and only a
>>> blank screen will be shown since there isn't a proper handoff from
>>> the simplefb driver to the Exynos DRM driver.
>>>
>>> Signed-off-by: Javier Martinez Canillas
>>>
>>> ---
>>>
>>> arch/arm/configs/exynos_defconfig | 1 -
>>> 1 file changed, 1 deletion(-)
>>
>> Seems logical. None of the boards use simple-framebuffer compatible
>> anyway. I understand that on Snow simplefb was needed along with change
>> in Uboot like this one:
>> https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/refs/changes/58/49358/2
>>
>
> Exactly but you won't see the dev node with the "simple-framebuffer"
> compatible string in the DTS since is the bootloader that adds this
> device node to the FDT before passing it to the kernel.
>
> The bootloader shouldn't mangle the FDT (with the exception of the
> memory and choosen/bootargs nodes) but simplefb is just a hack to
> re-use the display HW initialization made by the bootloader.
>
>> and now none of Exynos boards use simplefb anymore?
>>
>
> Yes, there are no other Exynos boards using simplefb besides Snow
> that I'm aware of but since Exynos DRM is working well on this board
> from v4.0, there is no need for it anymore.
OK,
Reviewed-by: Krzysztof Kozlowski
>
> In fact, as explained in the commit message, it could do more harm
> than good since users that are still booting with a u-boot that adds
> the simplefb device node, only get a blank screen since the simplefb
> driver is probed, creates a console and later the Exynos DRM probes
> and re-initializes the HW creating its own console, causing this issue.
>
> I got several reports of users that says that mainline stop booting for
> them but is just that they didn't get display working. Disabling simplefb
> makes display to work again so maybe this is even -rc material and should
> go to stable # v4.0+
You know, it is only a defconfig. The issue is there regardless of
change in defconfig. I am not convinced that defconfig problems are
worth backporting. multi_v7 has it enabled anyway.
Maybe the EXYNOS_DRM should have some anti-dependency on SIMPLE_FB? But
on the other hand the issue is actually caused by hacks in bootloader...
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ARM: dts: support Highspeed for rk3188-radxarock
Add cap-sd-highspeed and cap-mmc-highspeed for rk3188-radxarock board to make sd cards running faster. Signed-off-by: Shawn Lin --- arch/arm/boot/dts/rk3188-radxarock.dts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts b/arch/arm/boot/dts/rk3188-radxarock.dts index d2180e5..2f37ea7 100644 --- a/arch/arm/boot/dts/rk3188-radxarock.dts +++ b/arch/arm/boot/dts/rk3188-radxarock.dts @@ -287,7 +287,8 @@ pinctrl-names = "default"; pinctrl-0 = <&sd0_clk>, <&sd0_cmd>, <&sd0_cd>, <&sd0_bus4>; vmmc-supply = <&vcc_sd0>; - + cap-mmc-highspeed; + cap-sd-highspeed; bus-width = <4>; disable-wp; }; -- 2.3.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ARM: dts: support Highspeed for rk3066a platform
Add cap-sd-highspeed and cap-mmc-highspeed for rk3066a
platform to make sd cards running faster.
Signed-off-by: Shawn Lin
---
arch/arm/boot/dts/rk3066a.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 946f187..b50a785 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -595,6 +595,8 @@
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_cd &sd0_bus4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
&mmc1 {
--
2.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 00/16] staging: rtl8192u: code clean up
Hi,
Following comments from Dan Carpenter on my previous patch to
limit the lines lengths for rtl8192u/r8192U_core.c [1], please
find attached a set of patches splitting those operations.
I also took care of keeping the code the more readable possible,
some of those patchs even aim to clean the original content.
The last patch gets rid of the last WARNING of checkpatch about
the 80 lines, as well as the TO_DO_LIST macro that was used in
that module to comment out unused or unusable code.
Thanks,
- R.
[1]: https://lkml.org/lkml/2015/8/19/173
Raphaël Beamonte (16):
staging: rtl8192u: r8192U_core: fix comments lines over 80 characters
staging: rtl8192u: r8192U_core: add line breaks to keep lines under 80
characters
staging: rtl8192u: r8192U_core: add temporary variables to keep lines
under 80 characters
staging: rtl8192u: r8192U_core: reverse conditions to get lines under
80 characters
staging: rtl8192u: r8192U_core: rtl8192_adapter_start: reorganize
function
staging: rtl8192u: r8192U_core: rtl8192_read_eeprom_info: reorganize
function
staging: rtl8192u: r8192U_core: rtl8192_process_phyinfo: rename
variable pprevious_stats to prev_stats
staging: rtl8192u: r8192U_core: rtl8192_process_phyinfo: rename
variable slide_beacon_adc_pwdb_index to sb_index
staging: rtl8192u: r8192U_core: rtl8192_process_phyinfo: rename
variable slide_beacon_adc_pwdb_statistics to sb_stats
staging: rtl8192u: r8192U_core: rtl8192_process_phyinfo: remove
unneeded variable
staging: rtl8192u: r8192U_core: rtl8192_process_phyinfo: rename
variable rfpath to rfp
staging: rtl8192u: r8192U_core: rtl8192_process_phyinfo: reorganize
function
staging: rtl8192u: r8192U_core: rtl8192_tx: replace some inline
conditions
staging: rtl8192u: r8192U_core: rtl8192_ioctl: reorganize function
staging: rtl8192u: r8192U_core: replace else { if() {} } by else if ()
{}
staging: rtl8192u: remove all code framed by symbol TO_DO_LIST
drivers/staging/rtl8192u/ieee80211/ieee80211.h |4 +-
drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c | 23 -
.../staging/rtl8192u/ieee80211/rtl819x_HTProc.c|4 -
.../staging/rtl8192u/ieee80211/rtl819x_TSProc.c|5 +-
drivers/staging/rtl8192u/r8192U_core.c | 1548
drivers/staging/rtl8192u/r819xU_phy.c | 57 -
6 files changed, 940 insertions(+), 701 deletions(-)
--
2.5.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/
[PATCHv2 03/16] staging: rtl8192u: r8192U_core: add temporary variables to keep lines under 80 characters
Add some temporary variables to reduce line length under the maximum
of 80 characters, as per the kernel code style.
Signed-off-by: Raphaël Beamonte
---
drivers/staging/rtl8192u/r8192U_core.c | 139 ++---
1 file changed, 94 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 37c17eb..c8724cd 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -177,6 +177,7 @@ static void rtl819x_set_channel_map(u8 channel_plan, struct
r8192_priv *priv)
{
int i, max_chan = -1, min_chan = -1;
struct ieee80211_device *ieee = priv->ieee80211;
+ struct CHANNEL_LIST cl;
switch (channel_plan) {
case COUNTRY_CODE_FCC:
@@ -200,15 +201,18 @@ static void rtl819x_set_channel_map(u8 channel_plan,
struct r8192_priv *priv)
"unknown rf chip, can't set channel map in
function:%s()\n",
__func__);
}
- if (ChannelPlan[channel_plan].Len != 0) {
+ cl = ChannelPlan[channel_plan];
+ if (cl.Len != 0) {
/* Clear old channel map */
memset(GET_DOT11D_INFO(ieee)->channel_map, 0,
sizeof(GET_DOT11D_INFO(ieee)->channel_map));
/* Set new channel map */
- for (i = 0; i < ChannelPlan[channel_plan].Len; i++) {
- if (ChannelPlan[channel_plan].Channel[i] <
min_chan || ChannelPlan[channel_plan].Channel[i] > max_chan)
+ for (i = 0; i < cl.Len; i++) {
+ u8 chan = cl.Channel[i];
+
+ if (chan < min_chan || chan > max_chan)
break;
-
GET_DOT11D_INFO(ieee)->channel_map[ChannelPlan[channel_plan].Channel[i]] = 1;
+ GET_DOT11D_INFO(ieee)->channel_map[chan] = 1;
}
}
break;
@@ -1699,9 +1703,12 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff
*skb)
&zero, 0, tx_zero_isr, dev);
status = usb_submit_urb(tx_urb_zero, GFP_ATOMIC);
if (status) {
+ atomic_t tx =
+ priv->tx_pending[tcb_desc->queue_index];
+
RT_TRACE(COMP_ERR,
"Error TX URB for zero byte %d, error
%d",
-
atomic_read(&priv->tx_pending[tcb_desc->queue_index]),
+atomic_read(&tx),
status);
return -1;
}
@@ -1748,8 +1755,9 @@ static short rtl8192_usb_initendpoints(struct net_device
*dev)
oldaddr = priv->oldaddr;
align = ((long)oldaddr) & 3;
if (align) {
- newaddr = oldaddr + 4 - align;
- priv->rx_urb[16]->transfer_buffer_length = 16 - 4 +
align;
+ align = 4 - align;
+ newaddr = oldaddr + align;
+ priv->rx_urb[16]->transfer_buffer_length = 16 - align;
} else {
newaddr = oldaddr;
priv->rx_urb[16]->transfer_buffer_length = 16;
@@ -1913,7 +1921,9 @@ static void rtl8192_qos_activate(struct work_struct *work)
*/
for (i = 0; i < QOS_QUEUE_NUM; i++) {
/* Mode G/A: slotTimeTimer = 9; Mode B: 20 */
- u1bAIFS = qos_parameters->aifs[i] * ((mode & (IEEE_G |
IEEE_N_24G)) ? 9 : 20) + aSifsTime;
+ int slotTimeTimer = ((mode & (IEEE_G | IEEE_N_24G)) ? 9 : 20);
+
+ u1bAIFS = qos_parameters->aifs[i] * slotTimeTimer + aSifsTime;
u1bAIFS <<= AC_PARAM_AIFS_OFFSET;
op_limit = (u32)le16_to_cpu(qos_parameters->tx_op_limit[i]);
op_limit <<= AC_PARAM_TXOP_LIMIT_OFFSET;
@@ -2121,10 +2131,12 @@ static bool GetNmodeSupportBySecCfg8192(struct
net_device *dev)
return false;
} else if ((wpa_ie_len != 0)) {
/* parse pairwise key type */
- if (((ieee->wpa_ie[0] == 0xdd) && (!memcmp(&(ieee->wpa_ie[14]),
ccmp_ie, 4))) || ((ieee->wpa_ie[0] == 0x30) && (!memcmp(&ieee->wpa_ie[10],
ccmp_rsn_ie, 4
- return true;
- else
- return false;
+ bool wpaie_dd = (ieee->wpa_ie[0] == 0xdd &&
+!memcmp(&ieee->wpa_ie[14], ccmp_ie, 4));
+ bool wpaie_30 = (ieee->wpa_ie[0] == 0x30 &&
+!memcmp(&ieee->wpa_ie[10],
[PATCHv2 08/16] staging: rtl8192u: r8192U_core: rtl8192_process_phyinfo: rename variable slide_beacon_adc_pwdb_index to sb_index
Rename variable to a shorter name to allow easier code
refactoring in following patch.
Signed-off-by: Raphaël Beamonte
---
drivers/staging/rtl8192u/r8192U_core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 2a7d46d..25c4cbd 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4053,7 +4053,7 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
static u32 slide_evm_index, slide_evm_statistics;
static u32 last_rssi, last_evm;
- static u32 slide_beacon_adc_pwdb_index;
+ static u32 sb_index;
static u32 slide_beacon_adc_pwdb_statistics;
static u32 last_beacon_adc_pwdb;
@@ -4150,14 +4150,14 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
/* record the beacon pwdb to the sliding window. */
if (slide_beacon_adc_pwdb_statistics++ >=
PHY_Beacon_RSSI_SLID_WIN_MAX) {
slide_beacon_adc_pwdb_statistics =
PHY_Beacon_RSSI_SLID_WIN_MAX;
- last_beacon_adc_pwdb =
priv->stats.Slide_Beacon_pwdb[slide_beacon_adc_pwdb_index];
+ last_beacon_adc_pwdb =
priv->stats.Slide_Beacon_pwdb[sb_index];
priv->stats.Slide_Beacon_Total -= last_beacon_adc_pwdb;
}
priv->stats.Slide_Beacon_Total += prev_stats->RxPWDBAll;
- priv->stats.Slide_Beacon_pwdb[slide_beacon_adc_pwdb_index] =
prev_stats->RxPWDBAll;
- slide_beacon_adc_pwdb_index++;
- if (slide_beacon_adc_pwdb_index >= PHY_Beacon_RSSI_SLID_WIN_MAX)
- slide_beacon_adc_pwdb_index = 0;
+ priv->stats.Slide_Beacon_pwdb[sb_index] = prev_stats->RxPWDBAll;
+ sb_index++;
+ if (sb_index >= PHY_Beacon_RSSI_SLID_WIN_MAX)
+ sb_index = 0;
prev_stats->RxPWDBAll = priv->stats.Slide_Beacon_Total /
slide_beacon_adc_pwdb_statistics;
if (prev_stats->RxPWDBAll >= 3)
prev_stats->RxPWDBAll -= 3;
--
2.5.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/
[PATCHv2 06/16] staging: rtl8192u: r8192U_core: rtl8192_read_eeprom_info: reorganize function
Refactor code to avoid multiple check of same boolean value, and to
make the code clearer. This patches also implements the necessary
changes for the code lines in this function to be under 80 chars.
Signed-off-by: Raphaël Beamonte
---
drivers/staging/rtl8192u/r8192U_core.c | 259 -
1 file changed, 155 insertions(+), 104 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 5573c50..acb8f97 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -2497,129 +2497,180 @@ static void rtl8192_read_eeprom_info(struct
net_device *dev)
priv->rf_type = RTL819X_DEFAULT_RF_TYPE; /* default 1T2R */
priv->rf_chip = RF_8256;
- if (priv->card_8192_version == (u8)VERSION_819xU_A) {
+ /* if version mismatch VERSION_819xU_A, go directly to the led section
+*/
+ if (priv->card_8192_version != (u8)VERSION_819xU_A)
+ goto led;
+
+ if (bLoad_From_EEPOM) {
/* read Tx power gain offset of legacy OFDM to HT rate */
- if (bLoad_From_EEPOM)
- priv->EEPROMTxPowerDiff = (eprom_read(dev,
(EEPROM_TxPowerDiff >> 1)) & 0xff00) >> 8;
- else
- priv->EEPROMTxPowerDiff = EEPROM_Default_TxPower;
- RT_TRACE(COMP_EPROM, "TxPowerDiff:%d\n",
priv->EEPROMTxPowerDiff);
+ tmpValue = eprom_read(dev, (EEPROM_TxPowerDiff >> 1));
+ priv->EEPROMTxPowerDiff = (tmpValue & 0xff00) >> 8;
+
/* read ThermalMeter from EEPROM */
- if (bLoad_From_EEPOM)
- priv->EEPROMThermalMeter = (u8)(eprom_read(dev,
(EEPROM_ThermalMeter >> 1)) & 0x00ff);
- else
- priv->EEPROMThermalMeter = EEPROM_Default_ThermalMeter;
- RT_TRACE(COMP_EPROM, "ThermalMeter:%d\n",
priv->EEPROMThermalMeter);
- /* for tx power track */
- priv->TSSI_13dBm = priv->EEPROMThermalMeter * 100;
+ tmpValue = eprom_read(dev, (EEPROM_ThermalMeter >> 1));
+ priv->EEPROMThermalMeter = (u8)(tmpValue & 0x00ff);
+
/* read antenna tx power offset of B/C/D to A from EEPROM */
- if (bLoad_From_EEPOM)
- priv->EEPROMPwDiff = (eprom_read(dev, (EEPROM_PwDiff >>
1)) & 0x0f00) >> 8;
- else
- priv->EEPROMPwDiff = EEPROM_Default_PwDiff;
- RT_TRACE(COMP_EPROM, "TxPwDiff:%d\n", priv->EEPROMPwDiff);
+ tmpValue = eprom_read(dev, (EEPROM_PwDiff >> 1));
+ priv->EEPROMPwDiff = (tmpValue & 0x0f00) >> 8;
+
/* Read CrystalCap from EEPROM */
- if (bLoad_From_EEPOM)
- priv->EEPROMCrystalCap = (eprom_read(dev,
(EEPROM_CrystalCap >> 1)) & 0x0f);
- else
- priv->EEPROMCrystalCap = EEPROM_Default_CrystalCap;
- RT_TRACE(COMP_EPROM, "CrystalCap = %d\n",
priv->EEPROMCrystalCap);
+ tmpValue = eprom_read(dev, (EEPROM_CrystalCap >> 1));
+ priv->EEPROMCrystalCap = (tmpValue & 0x0f);
+
/* get per-channel Tx power level */
- if (bLoad_From_EEPOM)
- priv->EEPROM_Def_Ver = (eprom_read(dev,
(EEPROM_TxPwIndex_Ver >> 1)) & 0xff00) >> 8;
- else
- priv->EEPROM_Def_Ver = 1;
- RT_TRACE(COMP_EPROM, "EEPROM_DEF_VER:%d\n",
priv->EEPROM_Def_Ver);
+ tmpValue = eprom_read(dev, (EEPROM_TxPwIndex_Ver >> 1));
+ priv->EEPROM_Def_Ver = (tmpValue & 0xff00) >> 8;
+ } else {
+ /* read Tx power gain offset of legacy OFDM to HT rate */
+ priv->EEPROMTxPowerDiff = EEPROM_Default_TxPower;
+
+ /* read ThermalMeter from EEPROM */
+ priv->EEPROMThermalMeter = EEPROM_Default_ThermalMeter;
+
+ /* read antenna tx power offset of B/C/D to A from EEPROM */
+ priv->EEPROMPwDiff = EEPROM_Default_PwDiff;
+
+ /* Read CrystalCap from EEPROM */
+ priv->EEPROMCrystalCap = EEPROM_Default_CrystalCap;
+
+ /* get per-channel Tx power level */
+ priv->EEPROM_Def_Ver = 1;
+ }
+
+ /* for tx power track */
+ priv->TSSI_13dBm = priv->EEPROMThermalMeter * 100;
+
+ RT_TRACE(COMP_EPROM, "TxPowerDiff:%d\n", priv->EEPROMTxPowerDiff);
+ RT_TRACE(COMP_EPROM, "ThermalMeter:%d\n", priv->EEPROMThermalMeter);
+ RT_TRACE(COMP_EPROM, "TxPwDiff:%d\n", priv->EEPROMPwDiff);
+ RT_TRACE(COMP_EPROM, "CrystalCap = %d\n", priv->EEPROMCrystalCap);
+ RT_TRACE(COMP_EPROM, "EEPROM_DEF_VER:%d\n", priv->EEPROM_Def_Ver);
+
+ if (bLoad_From_EEPOM) {
if (priv->EEPROM_Def_Ver == 0) { /* old eeprom definition */
int i;
-
[PATCHv2 07/16] staging: rtl8192u: r8192U_core: rtl8192_process_phyinfo: rename variable pprevious_stats to prev_stats
Rename variable to a shorter name to allow easier code refactoring
in following patch.
Signed-off-by: Raphaël Beamonte
---
drivers/staging/rtl8192u/r8192U_core.c | 84 +-
1 file changed, 42 insertions(+), 42 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index acb8f97..2a7d46d 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4043,7 +4043,7 @@ static long rtl819x_translate_todbm(u8
signal_strength_index)
* and it will be reinitialized when returned from S3/S4.
*/
static void rtl8192_process_phyinfo(struct r8192_priv *priv, u8 *buffer,
- struct ieee80211_rx_stats *pprevious_stats,
+ struct ieee80211_rx_stats *prev_stats,
struct ieee80211_rx_stats *pcurrent_stats)
{
bool bcheck = false;
@@ -4069,7 +4069,7 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
pcurrent_stats->Seq_Num = seq;
/* Check whether we should take the previous packet into accounting */
- if (!pprevious_stats->bIsAMPDU) {
+ if (!prev_stats->bIsAMPDU) {
/* if previous packet is not aggregated packet */
bcheck = true;
}
@@ -4079,10 +4079,10 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
last_rssi = priv->stats.slide_signal_strength[slide_rssi_index];
priv->stats.slide_rssi_total -= last_rssi;
}
- priv->stats.slide_rssi_total += pprevious_stats->SignalStrength;
+ priv->stats.slide_rssi_total += prev_stats->SignalStrength;
priv->stats.slide_signal_strength[slide_rssi_index++] =
- pprevious_stats->SignalStrength;
+ prev_stats->SignalStrength;
if (slide_rssi_index >= PHY_RSSI_SLID_WIN_MAX)
slide_rssi_index = 0;
@@ -4092,8 +4092,8 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
pcurrent_stats->rssi = priv->stats.signal_strength;
/* If the previous packet does not match the criteria, neglect it */
- if (!pprevious_stats->bPacketMatchBSSID) {
- if (!pprevious_stats->bToSelfBA)
+ if (!prev_stats->bPacketMatchBSSID) {
+ if (!prev_stats->bToSelfBA)
return;
}
@@ -4102,7 +4102,7 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
/* only rtl8190 supported
-* rtl8190_process_cck_rxpathsel(priv,pprevious_stats);
+* rtl8190_process_cck_rxpathsel(priv,prev_stats);
*/
/* Check RSSI */
@@ -4114,8 +4114,8 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
/* <2> Showed on UI for engineering
* hardware does not provide rssi information for each rf path in CCK
*/
- if (!pprevious_stats->bIsCCK &&
- (pprevious_stats->bPacketToSelf || pprevious_stats->bToSelfBA)) {
+ if (!prev_stats->bIsCCK &&
+ (prev_stats->bPacketToSelf || prev_stats->bToSelfBA)) {
for (rfpath = RF90_PATH_A; rfpath < priv->NumTotalRFPath;
rfpath++) {
if (!rtl8192_phy_CheckIsLegalRFPath(
priv->ieee80211->dev, rfpath))
@@ -4123,16 +4123,16 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
if (priv->stats.rx_rssi_percentage[rfpath] == 0)
priv->stats.rx_rssi_percentage[rfpath] =
-
pprevious_stats->RxMIMOSignalStrength[rfpath];
- if (pprevious_stats->RxMIMOSignalStrength[rfpath] >
priv->stats.rx_rssi_percentage[rfpath]) {
+
prev_stats->RxMIMOSignalStrength[rfpath];
+ if (prev_stats->RxMIMOSignalStrength[rfpath] >
priv->stats.rx_rssi_percentage[rfpath]) {
priv->stats.rx_rssi_percentage[rfpath] =
((priv->stats.rx_rssi_percentage[rfpath] * (Rx_Smooth_Factor - 1)) +
-
(pprevious_stats->RxMIMOSignalStrength[rfpath])) / (Rx_Smooth_Factor);
+
(prev_stats->RxMIMOSignalStrength[rfpath])) / (Rx_Smooth_Factor);
priv->stats.rx_rssi_percentage[rfpath] =
priv->stats.rx_rssi_percentage[rfpath] + 1;
} else {
priv->stats.rx_rssi_percentage[rfpath] =
((priv->stats.rx_rssi_percentage[rfpath] * (Rx_Smooth_Factor - 1)) +
-
(pprevious_stats->RxMIMOSignalStrength[rfpath])) / (Rx_Smooth_Factor);
+
(prev_stats->
[PATCHv2 04/16] staging: rtl8192u: r8192U_core: reverse conditions to get lines under 80 characters
Reverse some conditions to clean the code and allow to have lines
under 80 characters, as to follow the kernel code style.
Signed-off-by: Raphaël Beamonte
---
drivers/staging/rtl8192u/r8192U_core.c | 48 ++
1 file changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index c8724cd..85dfcbb 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -202,18 +202,19 @@ static void rtl819x_set_channel_map(u8 channel_plan,
struct r8192_priv *priv)
__func__);
}
cl = ChannelPlan[channel_plan];
- if (cl.Len != 0) {
- /* Clear old channel map */
- memset(GET_DOT11D_INFO(ieee)->channel_map, 0,
- sizeof(GET_DOT11D_INFO(ieee)->channel_map));
- /* Set new channel map */
- for (i = 0; i < cl.Len; i++) {
- u8 chan = cl.Channel[i];
-
- if (chan < min_chan || chan > max_chan)
- break;
- GET_DOT11D_INFO(ieee)->channel_map[chan] = 1;
- }
+ if (cl.Len == 0)
+ break;
+
+ /* Clear old channel map */
+ memset(GET_DOT11D_INFO(ieee)->channel_map, 0,
+ sizeof(GET_DOT11D_INFO(ieee)->channel_map));
+ /* Set new channel map */
+ for (i = 0; i < cl.Len; i++) {
+ u8 chan = cl.Channel[i];
+
+ if (chan < min_chan || chan > max_chan)
+ break;
+ GET_DOT11D_INFO(ieee)->channel_map[chan] = 1;
}
break;
@@ -1088,17 +1089,18 @@ static void rtl8192_tx_isr(struct urb *tx_urb)
*/
/* Handle MPDU in wait queue. */
- if (queue_index != BEACON_QUEUE) {
- /* Don't send data frame during scanning.*/
- if ((skb_queue_len(&priv->ieee80211->skb_waitQ[queue_index]) !=
0) &&
- (!(priv->ieee80211->queue_stop))) {
- skb =
skb_dequeue(&(priv->ieee80211->skb_waitQ[queue_index]));
- if (skb)
- priv->ieee80211->softmac_hard_start_xmit(skb,
-dev);
-
- return; /* avoid further processing AMSDU */
- }
+ if (queue_index == BEACON_QUEUE)
+ return;
+
+ /* Don't send data frame during scanning.*/
+ if ((skb_queue_len(&priv->ieee80211->skb_waitQ[queue_index]) != 0) &&
+ (!(priv->ieee80211->queue_stop))) {
+ skb = skb_dequeue(&(priv->ieee80211->skb_waitQ[queue_index]));
+ if (skb)
+ priv->ieee80211->softmac_hard_start_xmit(skb,
+dev);
+
+ return; /* avoid further processing AMSDU */
}
}
--
2.5.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/
[PATCHv2 05/16] staging: rtl8192u: r8192U_core: rtl8192_adapter_start: reorganize function
Reverse conditions and use goto in the function rtl8192_adapter_start
to have most of it under 80 characters per line.
Signed-off-by: Raphaël Beamonte
---
drivers/staging/rtl8192u/r8192U_core.c | 91 ++
1 file changed, 47 insertions(+), 44 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 85dfcbb..5573c50 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -2816,6 +2816,7 @@ static bool rtl8192_adapter_start(struct net_device *dev)
bool init_status = true;
u8 SECR_value = 0x0;
u8 tmp;
+ u32 i, TempCCk, tmpRegA;
RT_TRACE(COMP_INIT, ">%s()\n", __func__);
priv->Rf_Mode = RF_OP_By_SW_3wire;
@@ -2997,59 +2998,61 @@ static bool rtl8192_adapter_start(struct net_device
*dev)
rtl8192_setBBreg(dev, rFPGA0_RFMOD, bCCKEn, 0x1);
rtl8192_setBBreg(dev, rFPGA0_RFMOD, bOFDMEn, 0x1);
- if (priv->ResetProgress == RESET_TYPE_NORESET) {
- /* if D or C cut */
- u8 tmpvalue;
+ if (priv->ResetProgress != RESET_TYPE_NORESET)
+ goto end;
- read_nic_byte(dev, 0x301, &tmpvalue);
- if (tmpvalue == 0x03) {
- priv->bDcut = true;
- RT_TRACE(COMP_POWER_TRACKING, "D-cut\n");
- } else {
- priv->bDcut = false;
- RT_TRACE(COMP_POWER_TRACKING, "C-cut\n");
+ /* if D or C cut */
+ read_nic_byte(dev, 0x301, &tmp);
+ if (tmp == 0x03) {
+ priv->bDcut = true;
+ RT_TRACE(COMP_POWER_TRACKING, "D-cut\n");
+ } else {
+ priv->bDcut = false;
+ RT_TRACE(COMP_POWER_TRACKING, "C-cut\n");
+ }
+ dm_initialize_txpower_tracking(dev);
+
+ if (!priv->bDcut)
+ goto end;
+
+ tmpRegA = rtl8192_QueryBBReg(dev,
+rOFDM0_XATxIQImbalance,
+ bMaskDWord);
+
+ for (i = 0; i < TxBBGainTableLength; i++) {
+ txbbgain_struct tx = priv->txbbgain_table[i];
+
+ if (tmpRegA == tx.txbbgain_value) {
+ priv->rfa_txpowertrackingindex = (u8)i;
+ priv->rfa_txpowertrackingindex_real =
+ (u8)i;
+ priv->rfa_txpowertracking_default =
+ priv->rfa_txpowertrackingindex;
+ break;
}
- dm_initialize_txpower_tracking(dev);
-
- if (priv->bDcut) {
- u32 i, TempCCk;
- u32 tmpRegA = rtl8192_QueryBBReg(dev,
-rOFDM0_XATxIQImbalance,
-bMaskDWord);
- txbbgain_struct *tx = priv->txbbgain_table;
- ccktxbbgain_struct *cck = priv->cck_txbbgain_table;
-
- for (i = 0; i < TxBBGainTableLength; i++) {
- if (tmpRegA == tx[i].txbbgain_value) {
- priv->rfa_txpowertrackingindex = (u8)i;
- priv->rfa_txpowertrackingindex_real =
- (u8)i;
- priv->rfa_txpowertracking_default =
- priv->rfa_txpowertrackingindex;
- break;
- }
- }
+ }
- TempCCk = rtl8192_QueryBBReg(dev,
-rCCK0_TxFilter1,
-bMaskByte2);
+ TempCCk = rtl8192_QueryBBReg(dev,
+rCCK0_TxFilter1,
+bMaskByte2);
- for (i = 0; i < CCKTxBBGainTableLength; i++) {
- if (TempCCk == cck[i].ccktxbb_valuearray[0]) {
-
priv->cck_present_attentuation_20Mdefault = (u8)i;
- break;
- }
- }
- priv->cck_present_attentuation_40Mdefault = 0;
- priv->cck_present_attentuation_difference = 0;
- priv->cck_present_attentuation =
- priv->cck_present_attentuation_20Mdefault;
+ for (i = 0; i < CCKTxBBGainTableLength; i++) {
+ ccktxbbgain_struct cck = priv->cck_txbbgain_table[i];
+ if (TempCCk == cck.ccktxbb_valuearray[0]) {
+ priv->cck_present_attentuation_20Mdefault = (u8)i;
+ break;
[PATCHv2 09/16] staging: rtl8192u: r8192U_core: rtl8192_process_phyinfo: rename variable slide_beacon_adc_pwdb_statistics to sb_stats
Rename variable to a shorter name to allow easier code
refactoring in following patch.
Signed-off-by: Raphaël Beamonte
---
drivers/staging/rtl8192u/r8192U_core.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 25c4cbd..d779506 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4054,7 +4054,7 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
static u32 last_rssi, last_evm;
static u32 sb_index;
- static u32 slide_beacon_adc_pwdb_statistics;
+ static u32 sb_stats;
static u32 last_beacon_adc_pwdb;
struct rtl_80211_hdr_3addr *hdr;
@@ -4148,8 +4148,8 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
if (prev_stats->bPacketBeacon) {
/* record the beacon pwdb to the sliding window. */
- if (slide_beacon_adc_pwdb_statistics++ >=
PHY_Beacon_RSSI_SLID_WIN_MAX) {
- slide_beacon_adc_pwdb_statistics =
PHY_Beacon_RSSI_SLID_WIN_MAX;
+ if (sb_stats++ >= PHY_Beacon_RSSI_SLID_WIN_MAX) {
+ sb_stats = PHY_Beacon_RSSI_SLID_WIN_MAX;
last_beacon_adc_pwdb =
priv->stats.Slide_Beacon_pwdb[sb_index];
priv->stats.Slide_Beacon_Total -= last_beacon_adc_pwdb;
}
@@ -4158,7 +4158,7 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
sb_index++;
if (sb_index >= PHY_Beacon_RSSI_SLID_WIN_MAX)
sb_index = 0;
- prev_stats->RxPWDBAll = priv->stats.Slide_Beacon_Total /
slide_beacon_adc_pwdb_statistics;
+ prev_stats->RxPWDBAll = priv->stats.Slide_Beacon_Total /
sb_stats;
if (prev_stats->RxPWDBAll >= 3)
prev_stats->RxPWDBAll -= 3;
}
--
2.5.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/
[PATCHv2 01/16] staging: rtl8192u: r8192U_core: fix comments lines over 80 characters
Move, replace and reorganize comments to stay under 80 characters
per line, as to follow the kernel code style. Some unuseful comments
have been removed.
Signed-off-by: Raphaël Beamonte
---
drivers/staging/rtl8192u/r8192U_core.c | 232 ++---
1 file changed, 153 insertions(+), 79 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index b143b36..5e9d0ac 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -143,17 +143,28 @@ struct CHANNEL_LIST {
};
static struct CHANNEL_LIST ChannelPlan[] = {
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64,
149, 153, 157, 161, 165}, 24}, /* FCC */
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11}, 11},
/* IC */
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40, 44, 48, 52, 56,
60, 64}, 21}, /* ETSI */
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},
/* Spain. Change to ETSI. */
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},
/* France. Change to ETSI. */
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
56, 60, 64}, 22}, /* MKK */
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
56, 60, 64}, 22}, /* MKK1 */
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},
/* Israel. */
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
56, 60, 64}, 22}, /* For 11a , TELEC */
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
56, 60, 64}, 22}, /* MIC */
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14}, 14} /* For Global
Domain. 1-11:active scan, 12-14 passive scan. */
+ /* FCC */
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64,
149, 153, 157, 161, 165}, 24},
+ /* IC */
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11}, 11},
+ /* ETSI */
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40, 44, 48, 52, 56,
60, 64}, 21},
+ /* Spain. Change to ETSI. */
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},
+ /* France. Change to ETSI. */
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},
+ /* MKK */
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
56, 60, 64}, 22},
+ /* MKK1 */
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
56, 60, 64}, 22},
+ /* Israel. */
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},
+ /* For 11a , TELEC */
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
56, 60, 64}, 22},
+ /* MIC */
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
56, 60, 64}, 22},
+ /* For Global Domain. 1-11:active scan, 12-14 passive scan. */
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14}, 14}
};
static void rtl819x_set_channel_map(u8 channel_plan, struct r8192_priv *priv)
@@ -194,7 +205,10 @@ static void rtl819x_set_channel_map(u8 channel_plan,
struct r8192_priv *priv)
break;
case COUNTRY_CODE_GLOBAL_DOMAIN:
- GET_DOT11D_INFO(ieee)->bEnabled = 0; /* this flag enabled to
follow 11d country IE setting, otherwise, it shall follow global domain
settings. */
+ /* this flag enabled to follow 11d country IE setting,
+* otherwise, it shall follow global domain settings.
+*/
+ GET_DOT11D_INFO(ieee)->bEnabled = 0;
Dot11d_Reset(ieee);
ieee->bGlobalDomain = true;
break;
@@ -210,9 +224,11 @@ static void rtl819x_set_channel_map(u8 channel_plan,
struct r8192_priv *priv)
static void CamResetAllEntry(struct net_device *dev)
{
u32 ulcommand = 0;
- /* 2004/02/11 In static WEP, OID_ADD_KEY or OID_ADD_WEP are set before
STA associate to AP.
-* However, ResetKey is called on OID_802_11_INFRASTRUCTURE_MODE and
MlmeAssociateRequest
-* In this condition, Cam can not be reset because upper layer will
not set this static key again.
+ /* In static WEP, OID_ADD_KEY or OID_ADD_WEP are set before STA
+* associate to AP. However, ResetKey is called on
+* OID_802_11_INFRASTRUCTURE_MODE and MlmeAssociateRequest. In this
+* condition, Cam can not be reset because upper layer will not set
+* this static key again.
*/
ulcommand |= BIT31 | BIT30;
write_nic_dword(dev, RWCAM, ulcommand);
@@ -1039,8 +1055,9 @@ static void rtl8192_tx_isr(struct urb *tx_urb)
*
* Caution:
* Handling the wait
[PATCHv2 13/16] staging: rtl8192u: r8192U_core: rtl8192_tx: replace some inline conditions
Replace some inline conditions by a full if-else statement to make
the source clearer and follow the 80 characters kernel code style
rule.
Signed-off-by: Raphaël Beamonte
---
drivers/staging/rtl8192u/r8192U_core.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index ba33b96..189de56 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1596,12 +1596,18 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff
*skb)
tx_fwinfo->RtsEnable = (tcb_desc->bRTSEnable) ? 1 : 0;
tx_fwinfo->CtsEnable = (tcb_desc->bCTSEnable) ? 1 : 0;
tx_fwinfo->RtsSTBC = (tcb_desc->bRTSSTBC) ? 1 : 0;
- tx_fwinfo->RtsHT = (tcb_desc->rts_rate & 0x80) ? 1 : 0;
tx_fwinfo->RtsRate = MRateToHwRate8190Pci((u8)tcb_desc->rts_rate);
- tx_fwinfo->RtsSubcarrier = (tx_fwinfo->RtsHT == 0) ? (tcb_desc->RTSSC)
: 0;
- tx_fwinfo->RtsBandwidth = (tx_fwinfo->RtsHT == 1) ? ((tcb_desc->bRTSBW)
? 1 : 0) : 0;
- tx_fwinfo->RtsShort = (tx_fwinfo->RtsHT == 0) ?
(tcb_desc->bRTSUseShortPreamble ? 1 : 0) :
- (tcb_desc->bRTSUseShortGI ? 1 : 0);
+ if (tcb_desc->rts_rate & 0x80) {
+ tx_fwinfo->RtsHT = 1;
+ tx_fwinfo->RtsSubcarrier = 0;
+ tx_fwinfo->RtsBandwidth = (tcb_desc->bRTSBW) ? 1 : 0;
+ tx_fwinfo->RtsShort = (tcb_desc->bRTSUseShortGI ? 1 : 0);
+ } else {
+ tx_fwinfo->RtsHT = 0;
+ tx_fwinfo->RtsSubcarrier = tcb_desc->RTSSC;
+ tx_fwinfo->RtsBandwidth = 0;
+ tx_fwinfo->RtsShort = (tcb_desc->bRTSUseShortPreamble ? 1 : 0);
+ }
/* Set Bandwidth and sub-channel settings. */
if (priv->CurrentChannelBW == HT_CHANNEL_WIDTH_20_40) {
--
2.5.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/
[PATCHv2 10/16] staging: rtl8192u: r8192U_core: rtl8192_process_phyinfo: remove unneeded variable
Local variable last_beacon_adc_pwdb was used to store a value that wasn't
used after. This patch removes that variable.
Signed-off-by: Raphaël Beamonte
---
drivers/staging/rtl8192u/r8192U_core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index d779506..100fbbe 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4055,7 +4055,6 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
static u32 sb_index;
static u32 sb_stats;
- static u32 last_beacon_adc_pwdb;
struct rtl_80211_hdr_3addr *hdr;
u16 sc;
@@ -4150,8 +4149,8 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
/* record the beacon pwdb to the sliding window. */
if (sb_stats++ >= PHY_Beacon_RSSI_SLID_WIN_MAX) {
sb_stats = PHY_Beacon_RSSI_SLID_WIN_MAX;
- last_beacon_adc_pwdb =
priv->stats.Slide_Beacon_pwdb[sb_index];
- priv->stats.Slide_Beacon_Total -= last_beacon_adc_pwdb;
+ priv->stats.Slide_Beacon_Total -=
+ priv->stats.Slide_Beacon_pwdb[sb_index];
}
priv->stats.Slide_Beacon_Total += prev_stats->RxPWDBAll;
priv->stats.Slide_Beacon_pwdb[sb_index] = prev_stats->RxPWDBAll;
--
2.5.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/
[PATCHv2 11/16] staging: rtl8192u: r8192U_core: rtl8192_process_phyinfo: rename variable rfpath to rfp
Rename variable to a shorter name to allow easier code
refactoring in following patches.
Signed-off-by: Raphaël Beamonte
---
drivers/staging/rtl8192u/r8192U_core.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 100fbbe..6bc92a7 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4047,7 +4047,7 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
struct ieee80211_rx_stats *pcurrent_stats)
{
bool bcheck = false;
- u8 rfpath;
+ u8 rfp;
u32 nspatial_stream, tmp_val;
static u32 slide_rssi_index, slide_rssi_statistics;
static u32 slide_evm_index, slide_evm_statistics;
@@ -4115,27 +4115,28 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
*/
if (!prev_stats->bIsCCK &&
(prev_stats->bPacketToSelf || prev_stats->bToSelfBA)) {
- for (rfpath = RF90_PATH_A; rfpath < priv->NumTotalRFPath;
rfpath++) {
+ for (rfp = RF90_PATH_A; rfp < priv->NumTotalRFPath; rfp++) {
if (!rtl8192_phy_CheckIsLegalRFPath(
- priv->ieee80211->dev, rfpath))
+ priv->ieee80211->dev, rfp))
continue;
- if (priv->stats.rx_rssi_percentage[rfpath] == 0)
- priv->stats.rx_rssi_percentage[rfpath] =
-
prev_stats->RxMIMOSignalStrength[rfpath];
- if (prev_stats->RxMIMOSignalStrength[rfpath] >
priv->stats.rx_rssi_percentage[rfpath]) {
- priv->stats.rx_rssi_percentage[rfpath] =
-
((priv->stats.rx_rssi_percentage[rfpath] * (Rx_Smooth_Factor - 1)) +
-
(prev_stats->RxMIMOSignalStrength[rfpath])) / (Rx_Smooth_Factor);
- priv->stats.rx_rssi_percentage[rfpath] =
priv->stats.rx_rssi_percentage[rfpath] + 1;
+ if (priv->stats.rx_rssi_percentage[rfp] == 0)
+ priv->stats.rx_rssi_percentage[rfp] =
+ prev_stats->RxMIMOSignalStrength[rfp];
+
+ if (prev_stats->RxMIMOSignalStrength[rfp] >
priv->stats.rx_rssi_percentage[rfp]) {
+ priv->stats.rx_rssi_percentage[rfp] =
+ ((priv->stats.rx_rssi_percentage[rfp] *
(Rx_Smooth_Factor - 1)) +
+
(prev_stats->RxMIMOSignalStrength[rfp])) / (Rx_Smooth_Factor);
+ priv->stats.rx_rssi_percentage[rfp] =
priv->stats.rx_rssi_percentage[rfp] + 1;
} else {
- priv->stats.rx_rssi_percentage[rfpath] =
-
((priv->stats.rx_rssi_percentage[rfpath] * (Rx_Smooth_Factor - 1)) +
-
(prev_stats->RxMIMOSignalStrength[rfpath])) / (Rx_Smooth_Factor);
+ priv->stats.rx_rssi_percentage[rfp] =
+ ((priv->stats.rx_rssi_percentage[rfp] *
(Rx_Smooth_Factor - 1)) +
+
(prev_stats->RxMIMOSignalStrength[rfp])) / (Rx_Smooth_Factor);
}
RT_TRACE(COMP_DBG,
"priv->stats.rx_rssi_percentage[rfPath] =
%d\n",
-priv->stats.rx_rssi_percentage[rfpath]);
+priv->stats.rx_rssi_percentage[rfp]);
}
}
--
2.5.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/
[PATCHv2 14/16] staging: rtl8192u: r8192U_core: rtl8192_ioctl: reorganize function
Reorganize function rtl8192_ioctl to replace a switch with only
one case besides the default by an if statement. This also allows
to follow the 80 characters kernel code style rule.
Signed-off-by: Raphaël Beamonte
---
drivers/staging/rtl8192u/r8192U_core.c | 141 -
1 file changed, 68 insertions(+), 73 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 189de56..f81f267 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -3801,82 +3801,77 @@ static int rtl8192_ioctl(struct net_device *dev, struct
ifreq *rq, int cmd)
goto out;
}
- switch (cmd) {
- case RTL_IOCTL_WPA_SUPPLICANT:
- /* parse here for HW security */
- if (ipw->cmd == IEEE_CMD_SET_ENCRYPTION) {
- if (ipw->u.crypt.set_tx) {
- if (strcmp(ipw->u.crypt.alg, "CCMP") == 0) {
- ieee->pairwise_key_type = KEY_TYPE_CCMP;
- } else if (strcmp(ipw->u.crypt.alg, "TKIP") ==
0) {
- ieee->pairwise_key_type = KEY_TYPE_TKIP;
- } else if (strcmp(ipw->u.crypt.alg, "WEP") ==
0) {
- if (ipw->u.crypt.key_len == 13)
- ieee->pairwise_key_type =
KEY_TYPE_WEP104;
- else if (ipw->u.crypt.key_len == 5)
- ieee->pairwise_key_type =
KEY_TYPE_WEP40;
- } else {
- ieee->pairwise_key_type = KEY_TYPE_NA;
- }
-
- if (ieee->pairwise_key_type) {
- memcpy((u8 *)key, ipw->u.crypt.key, 16);
- EnableHWSecurityConfig8192(dev);
- /* We fill both index entry and 4th
-* entry for pairwise key as in IPW
-* interface, adhoc will only get here,
-* so we need index entry for its
-* default key serching!
-*/
- setKey(dev, 4, ipw->u.crypt.idx,
- ieee->pairwise_key_type,
- (u8 *)ieee->ap_mac_addr,
- 0, key);
- if (ieee->auth_mode != 2)
- setKey(dev, ipw->u.crypt.idx,
- ipw->u.crypt.idx,
- ieee->pairwise_key_type,
- (u8 *)ieee->ap_mac_addr,
- 0, key);
- }
- } else {
- memcpy((u8 *)key, ipw->u.crypt.key, 16);
- if (strcmp(ipw->u.crypt.alg, "CCMP") == 0) {
- ieee->group_key_type = KEY_TYPE_CCMP;
- } else if (strcmp(ipw->u.crypt.alg, "TKIP") ==
0) {
- ieee->group_key_type = KEY_TYPE_TKIP;
- } else if (strcmp(ipw->u.crypt.alg, "WEP") ==
0) {
- if (ipw->u.crypt.key_len == 13)
- ieee->group_key_type =
KEY_TYPE_WEP104;
- else if (ipw->u.crypt.key_len == 5)
- ieee->group_key_type =
KEY_TYPE_WEP40;
- } else {
- ieee->group_key_type = KEY_TYPE_NA;
- }
-
- if (ieee->group_key_type) {
- setKey(dev, ipw->u.crypt.idx,
- /* KeyIndex */
- ipw->u.crypt.idx,
- /* KeyType */
- ieee->group_key_type,
- /* MacAddr */
- broadcast_addr,
- /* DefaultKey */
- 0,
- /* KeyContent */
- key);
- }
- }
+ if
[PATCHv2 12/16] staging: rtl8192u: r8192U_core: rtl8192_process_phyinfo: reorganize function
Reorganize function to make it cleaner, and respect the 80 characters
kernel code style rule.
Signed-off-by: Raphaël Beamonte
---
drivers/staging/rtl8192u/r8192U_core.c | 140 +++--
1 file changed, 81 insertions(+), 59 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 6bc92a7..ba33b96 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4116,6 +4116,8 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
if (!prev_stats->bIsCCK &&
(prev_stats->bPacketToSelf || prev_stats->bToSelfBA)) {
for (rfp = RF90_PATH_A; rfp < priv->NumTotalRFPath; rfp++) {
+ u8 rx, add = 0;
+
if (!rtl8192_phy_CheckIsLegalRFPath(
priv->ieee80211->dev, rfp))
continue;
@@ -4124,16 +4126,16 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
priv->stats.rx_rssi_percentage[rfp] =
prev_stats->RxMIMOSignalStrength[rfp];
- if (prev_stats->RxMIMOSignalStrength[rfp] >
priv->stats.rx_rssi_percentage[rfp]) {
- priv->stats.rx_rssi_percentage[rfp] =
- ((priv->stats.rx_rssi_percentage[rfp] *
(Rx_Smooth_Factor - 1)) +
-
(prev_stats->RxMIMOSignalStrength[rfp])) / (Rx_Smooth_Factor);
- priv->stats.rx_rssi_percentage[rfp] =
priv->stats.rx_rssi_percentage[rfp] + 1;
- } else {
- priv->stats.rx_rssi_percentage[rfp] =
- ((priv->stats.rx_rssi_percentage[rfp] *
(Rx_Smooth_Factor - 1)) +
-
(prev_stats->RxMIMOSignalStrength[rfp])) / (Rx_Smooth_Factor);
- }
+ rx = priv->stats.rx_rssi_percentage[rfp];
+ if (prev_stats->RxMIMOSignalStrength[rfp] > rx)
+ add = 1;
+
+ rx *= Rx_Smooth_Factor - 1;
+ rx += prev_stats->RxMIMOSignalStrength[rfp];
+ rx /= Rx_Smooth_Factor;
+
+ priv->stats.rx_rssi_percentage[rfp] = rx + add;
+
RT_TRACE(COMP_DBG,
"priv->stats.rx_rssi_percentage[rfPath] =
%d\n",
priv->stats.rx_rssi_percentage[rfp]);
@@ -4153,12 +4155,17 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
priv->stats.Slide_Beacon_Total -=
priv->stats.Slide_Beacon_pwdb[sb_index];
}
+
priv->stats.Slide_Beacon_Total += prev_stats->RxPWDBAll;
priv->stats.Slide_Beacon_pwdb[sb_index] = prev_stats->RxPWDBAll;
+
sb_index++;
if (sb_index >= PHY_Beacon_RSSI_SLID_WIN_MAX)
sb_index = 0;
- prev_stats->RxPWDBAll = priv->stats.Slide_Beacon_Total /
sb_stats;
+
+ prev_stats->RxPWDBAll =
+ priv->stats.Slide_Beacon_Total / sb_stats;
+
if (prev_stats->RxPWDBAll >= 3)
prev_stats->RxPWDBAll -= 3;
}
@@ -4171,69 +4178,84 @@ static void rtl8192_process_phyinfo(struct r8192_priv
*priv, u8 *buffer,
if (prev_stats->bPacketToSelf ||
prev_stats->bPacketBeacon ||
prev_stats->bToSelfBA) {
+ long pwdb, add = 0;
+
if (priv->undecorated_smoothed_pwdb < 0)
/* initialize */
priv->undecorated_smoothed_pwdb =
prev_stats->RxPWDBAll;
- if (prev_stats->RxPWDBAll >
(u32)priv->undecorated_smoothed_pwdb) {
- priv->undecorated_smoothed_pwdb =
- (((priv->undecorated_smoothed_pwdb) *
(Rx_Smooth_Factor - 1)) +
-(prev_stats->RxPWDBAll)) / (Rx_Smooth_Factor);
- priv->undecorated_smoothed_pwdb =
priv->undecorated_smoothed_pwdb + 1;
- } else {
- priv->undecorated_smoothed_pwdb =
- (((priv->undecorated_smoothed_pwdb) *
(Rx_Smooth_Factor - 1)) +
-(prev_stats->RxPWDBAll)) / (Rx_Smooth_Factor);
- }
+ pwdb = priv->undecorated_smoothed_pwdb;
+
+ if (prev_stats->RxPWDBAll > (u32)pwdb)
+ add = 1;
+
+ pwdb *= Rx_Smooth_Factor - 1;
+ pwdb += prev_stats->RxPWDBAll;
+ pwdb /= Rx_Smooth_Factor;
+
+ priv->undecor
[PATCHv2 16/16] staging: rtl8192u: remove all code framed by symbol TO_DO_LIST
The symbol TO_DO_LIST was used in the code to frame sections
of code unused or unusable. This patch remove all code framed
by that symbol in this driver.
Signed-off-by: Raphaël Beamonte
---
drivers/staging/rtl8192u/ieee80211/ieee80211.h | 4 +-
drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c | 23 -
.../staging/rtl8192u/ieee80211/rtl819x_HTProc.c| 4 -
.../staging/rtl8192u/ieee80211/rtl819x_TSProc.c| 5 +-
drivers/staging/rtl8192u/r8192U_core.c | 102 ++---
drivers/staging/rtl8192u/r819xU_phy.c | 57
6 files changed, 9 insertions(+), 186 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
index d481a26..28ba7d2 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -1654,10 +1654,10 @@ struct ieee80211_device {
struct list_headRx_TS_Pending_List;
struct list_headRx_TS_Unused_List;
RX_TS_RECORDRxTsRecord[TOTAL_TS_NUM];
-//#ifdef TO_DO_LIST
+
RX_REORDER_ENTRYRxReorderEntry[128];
struct list_headRxReorder_Unused_List;
-//#endif
+
// Qos related. Added by Annie, 2005-11-01.
// PSTA_QOSpStaQos;
u8 ForcedPriority; // Force
per-packet priority 1~7. (default: 0, not to force it.)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
index fff8d58..7bbe934 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
@@ -318,13 +318,6 @@ static void ieee80211_tx_query_agg_cap(struct
ieee80211_device *ieee,
if (is_multicast_ether_addr(hdr->addr1))
return;
//check packet and mode later
-#ifdef TO_DO_LIST
- if(pTcb->PacketLength >= 4096)
- return;
- // For RTL819X, if pairwisekey = wep/tkip, we don't aggrregation.
- if(!Adapter->HalFunc.GetNmodeSupportBySecCfgHandler(Adapter))
- return;
-#endif
if(!ieee->GetNmodeSupportBySecCfg(ieee->dev))
{
return;
@@ -550,22 +543,6 @@ NO_PROTECTION:
static void ieee80211_txrate_selectmode(struct ieee80211_device *ieee,
cb_desc *tcb_desc)
{
-#ifdef TO_DO_LIST
- if(!IsDataFrame(pFrame))
- {
- pTcb->bTxDisableRateFallBack = true;
- pTcb->bTxUseDriverAssingedRate = true;
- pTcb->RATRIndex = 7;
- return;
- }
-
- if(pMgntInfo->ForcedDataRate!= 0)
- {
- pTcb->bTxDisableRateFallBack = true;
- pTcb->bTxUseDriverAssingedRate = true;
- return;
- }
-#endif
if(ieee->bTxDisableRateFallBack)
tcb_desc->bTxDisableRateFallBack = true;
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
index c27397b..87b1bb9 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
@@ -88,10 +88,6 @@ void HTUpdateDefaultSetting(struct ieee80211_device *ieee)
ieee->bTxDisableRateFallBack = 0;
ieee->bTxUseDriverAssingedRate = 0;
-#ifdef TO_DO_LIST
- // 8190 only. Assign duration operation mode to firmware
- pMgntInfo->bTxEnableFwCalcDur =
(BOOLEAN)pNdisCommon->bRegTxEnableFwCalcDur;
-#endif
// 8190 only, Realtek proprietary aggregation mode
// Set MPDUDensity=2, 1: Set MPDUDensity=2(32k) for Realtek AP and
set MPDUDensity=0(8k) for others
pHTInfo->bRegRT2RTAggregation = 1;//0: Set MPDUDensity=2, 1: Set
MPDUDensity=2(32k) for Realtek AP and set MPDUDensity=0(8k) for others
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
index f33c743..fb493a2 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
@@ -193,7 +193,7 @@ void TSInitialize(struct ieee80211_device *ieee)
}
// Initialize unused Rx Reorder List.
INIT_LIST_HEAD(&ieee->RxReorder_Unused_List);
-//#ifdef TO_DO_LIST
+
for(count = 0; count < REORDER_ENTRY_NUM; count++)
{
list_add_tail(
&pRxReorderEntry->List,&ieee->RxReorder_Unused_List);
@@ -201,7 +201,6 @@ void TSInitialize(struct ieee80211_device *ieee)
break;
pRxReorderEntry = &ieee->RxReorderEntry[count+1];
}
-//#endif
}
@@ -461,7 +460,6 @@ static void RemoveTsEntry(struct ieee80211_device *ieee,
PTS_COMMON_INFO pTs,
if(TxRxSelect == RX_DIR)
{
-//#ifdef TO_DO_LIST
PRX_REORDER_ENTRY pRxReorderEntry;
[PATCHv2 15/16] staging: rtl8192u: r8192U_core: replace else { if() {} } by else if () {}
An else block only contained an if statement. Replace that else
block by an else if block instead.
Signed-off-by: Raphaël Beamonte
---
drivers/staging/rtl8192u/r8192U_core.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index f81f267..0d169d0 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4563,15 +4563,13 @@ static void rtl8192_query_rxphystatus(struct r8192_priv
*priv,
pstats->SignalStrength =
precord_stats->SignalStrength =
(u8)(rtl819x_signal_scale_mapping((long)pwdb_all));
- } else {
+ } else if (rf_rx_num != 0) {
/* We can judge RX path number now. */
- if (rf_rx_num != 0) {
- long currsig = (total_rssi /= rf_rx_num);
+ long currsig = (total_rssi /= rf_rx_num);
- pstats->SignalStrength =
- precord_stats->SignalStrength =
- (u8)(rtl819x_signal_scale_mapping(currsig));
- }
+ pstats->SignalStrength =
+ precord_stats->SignalStrength =
+ (u8)(rtl819x_signal_scale_mapping(currsig));
}
} /* QueryRxPhyStatus8190Pci */
--
2.5.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 2/2] [media] media-device: split media initialization and registration
Hello Sakari, On 09/11/2015 07:51 AM, Sakari Ailus wrote: > Hi Javier, > > Javier Martinez Canillas wrote: >> Hello Sakari, >> >> On 09/10/2015 07:14 PM, Sakari Ailus wrote: >>> Hi Javier, >>> >>> Thanks for the set! A few comments below. >>> >> >> Thanks to you for your feedback. >> >>> Javier Martinez Canillas wrote: The media device node is registered and so made visible to user-space before entities are registered and links created which means that the media graph obtained by user-space could be only partially enumerated if that happens too early before all the graph has been created. To avoid this race condition, split the media init and registration in separate functions and only register the media device node when all the pending subdevices have been registered, either explicitly by the driver or asynchronously using v4l2_async_register_subdev(). Also, add a media_entity_cleanup() function that will destroy the graph_mutex that is initialized in media_entity_init(). Suggested-by: Sakari Ailus Signed-off-by: Javier Martinez Canillas --- drivers/media/common/siano/smsdvb-main.c | 1 + drivers/media/media-device.c | 38 +++ drivers/media/platform/exynos4-is/media-dev.c | 12 ++--- drivers/media/platform/omap3isp/isp.c | 11 +--- drivers/media/platform/s3c-camif/camif-core.c | 13 ++--- drivers/media/platform/vsp1/vsp1_drv.c| 19 ++ drivers/media/platform/xilinx/xilinx-vipp.c | 11 +--- drivers/media/usb/au0828/au0828-core.c| 26 +- drivers/media/usb/cx231xx/cx231xx-cards.c | 22 +++- drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 11 +--- drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 13 ++--- drivers/media/usb/siano/smsusb.c | 14 -- drivers/media/usb/uvc/uvc_driver.c| 9 +-- include/media/media-device.h | 2 ++ 14 files changed, 156 insertions(+), 46 deletions(-) diff --git a/drivers/media/common/siano/smsdvb-main.c b/drivers/media/common/siano/smsdvb-main.c index ab345490a43a..8a1ea2192439 100644 --- a/drivers/media/common/siano/smsdvb-main.c +++ b/drivers/media/common/siano/smsdvb-main.c @@ -617,6 +617,7 @@ static void smsdvb_media_device_unregister(struct smsdvb_client_t *client) if (!coredev->media_dev) return; media_device_unregister(coredev->media_dev); +media_device_cleanup(coredev->media_dev); kfree(coredev->media_dev); coredev->media_dev = NULL; #endif diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c index 745defb34b33..a8beb0b445a6 100644 --- a/drivers/media/media-device.c +++ b/drivers/media/media-device.c @@ -526,7 +526,7 @@ static void media_device_release(struct media_devnode *mdev) } /** - * media_device_register - register a media device + * media_device_init() - initialize a media device * @mdev:The media device * * The caller is responsible for initializing the media device before @@ -534,12 +534,11 @@ static void media_device_release(struct media_devnode *mdev) * * - dev must point to the parent device * - model must be filled with the device model name + * + * returns zero on success or a negative error code. */ -int __must_check __media_device_register(struct media_device *mdev, - struct module *owner) +int __must_check media_device_init(struct media_device *mdev) >>> >>> I think I suggested making media_device_init() return void as the only >>> remaining source of errors would be driver bugs. >>> >> >> Yes you did and I think I explained why I preferred to leave it as >> is and I thought we agreed :) > > I thought we agreed, too. But my understanding was that the agreement was > different. ;-) > Fair enough :) >> >> Currently media_device_register() is failing gracefully if a buggy >> driver is not setting mdev->dev. So changing media_device_init() to >> return void instead, would be a semantic change and if drivers are >> not checking that anymore, can lead to NULL pointer dereference bugs. > > Do we have such drivers? Would they ever have worked in the first place, as > media device registration would have failed? > Most likely we don't but since I'm changing all the drivers anyways, I'll take a look and change to void and propose a fix if I find something but it seems is just that the function is checking a condition that would not happen with the in-tree media drivers. I'll change to void and remove the return value check in drivers for v2. >> >>> I'd simply replace the
[PATCHv2 02/16] staging: rtl8192u: r8192U_core: add line breaks to keep lines under 80 characters
Add line breaks in multiple lines to keep them under 80 characters,
as to follow the kernel code style.
Signed-off-by: Raphaël Beamonte
---
drivers/staging/rtl8192u/r8192U_core.c | 626 ++---
1 file changed, 421 insertions(+), 205 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 5e9d0ac..37c17eb 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -144,25 +144,31 @@ struct CHANNEL_LIST {
static struct CHANNEL_LIST ChannelPlan[] = {
/* FCC */
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64,
149, 153, 157, 161, 165}, 24},
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64,
+ 149, 153, 157, 161, 165}, 24},
/* IC */
{{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11}, 11},
/* ETSI */
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40, 44, 48, 52, 56,
60, 64}, 21},
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40, 44, 48, 52, 56,
+ 60, 64}, 21},
/* Spain. Change to ETSI. */
{{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},
/* France. Change to ETSI. */
{{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},
/* MKK */
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
56, 60, 64}, 22},
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
+ 56, 60, 64}, 22},
/* MKK1 */
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
56, 60, 64}, 22},
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
+ 56, 60, 64}, 22},
/* Israel. */
{{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},
/* For 11a , TELEC */
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
56, 60, 64}, 22},
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
+ 56, 60, 64}, 22},
/* MIC */
- {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
56, 60, 64}, 22},
+ {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
+ 56, 60, 64}, 22},
/* For Global Domain. 1-11:active scan, 12-14 passive scan. */
{{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14}, 14}
};
@@ -190,11 +196,14 @@ static void rtl819x_set_channel_map(u8 channel_plan,
struct r8192_priv *priv)
min_chan = 1;
max_chan = 14;
} else {
- RT_TRACE(COMP_ERR, "unknown rf chip, can't set channel
map in function:%s()\n", __func__);
+ RT_TRACE(COMP_ERR,
+"unknown rf chip, can't set channel map in
function:%s()\n",
+__func__);
}
if (ChannelPlan[channel_plan].Len != 0) {
/* Clear old channel map */
- memset(GET_DOT11D_INFO(ieee)->channel_map, 0,
sizeof(GET_DOT11D_INFO(ieee)->channel_map));
+ memset(GET_DOT11D_INFO(ieee)->channel_map, 0,
+ sizeof(GET_DOT11D_INFO(ieee)->channel_map));
/* Set new channel map */
for (i = 0; i < ChannelPlan[channel_plan].Len; i++) {
if (ChannelPlan[channel_plan].Channel[i] <
min_chan || ChannelPlan[channel_plan].Channel[i] > max_chan)
@@ -262,7 +271,8 @@ void write_nic_byte_E(struct net_device *dev, int indx, u8
data)
indx | 0xfe00, 0, &data, 1, HZ / 2);
if (status < 0)
- netdev_err(dev, "write_nic_byte_E TimeOut! status: %d\n",
status);
+ netdev_err(dev, "write_nic_byte_E TimeOut! status: %d\n",
+ status);
}
int read_nic_byte_E(struct net_device *dev, int indx, u8 *data)
@@ -292,7 +302,8 @@ void write_nic_byte(struct net_device *dev, int indx, u8
data)
status = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
RTL8187_REQ_SET_REGS, RTL8187_REQT_WRITE,
-(indx & 0xff) | 0xff00, (indx >> 8) & 0x0f,
&data, 1, HZ / 2);
+(indx & 0xff) | 0xff00, (indx >> 8) & 0x0f,
+&data, 1, HZ / 2);
if (status < 0)
netdev_err(dev, "write_nic_byte TimeOut! status: %d\n", status);
@@ -311,7 +322,8 @@ void write_nic_word(struct net_device *dev, int indx, u16
data)
status = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
RTL8187_REQ_SET_REGS, RTL8187_REQT_WRITE,
-(indx & 0xff) | 0xff00, (indx >> 8) & 0x0f,
&data, 2, HZ / 2);
+(indx & 0xff) | 0xff00, (indx >> 8) & 0x0f,
+
[PATCH v2] cpufreq: imx: update the clock switch flow to support imx6ul
For i.MX6UL, the clock switch flow is slightly different from
other i.MX6 SOCs. It has a 'secondary_sel' clk that will be used
when the CPU freq is higher than 396MHz. So the clock switch flow in
'set_target' callback need to update to support i.MX6UL in the common
i.MX6 SOC cpufreq driver.
Signed-off-by: Bai Ping
---
change for v2:
add the missed 'clk_put' in imx6q_cpufreq_remove().
drivers/cpufreq/imx6q-cpufreq.c | 50 -
1 file changed, 45 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index 380a90d..9b4a7bd 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -30,6 +30,10 @@ static struct clk *pll1_sw_clk;
static struct clk *step_clk;
static struct clk *pll2_pfd2_396m_clk;
+/* clk used by i.MX6UL */
+static struct clk *pll2_bus_clk;
+static struct clk *secondary_sel_clk;
+
static struct device *cpu_dev;
static bool free_opp;
static struct cpufreq_frequency_table *freq_table;
@@ -91,16 +95,36 @@ static int imx6q_set_target(struct cpufreq_policy *policy,
unsigned int index)
* The setpoints are selected per PLL/PDF frequencies, so we need to
* reprogram PLL for frequency scaling. The procedure of reprogramming
* PLL1 is as below.
-*
+* For i.MX6UL, it has a secondary clk mux, the cpu frequency change
+* flow is slightly different from other i.MX6 OSC.
+* The cpu frequeny change flow for i.MX6(except i.MX6UL) is as below:
* - Enable pll2_pfd2_396m_clk and reparent pll1_sw_clk to it
* - Reprogram pll1_sys_clk and reparent pll1_sw_clk back to it
* - Disable pll2_pfd2_396m_clk
*/
- clk_set_parent(step_clk, pll2_pfd2_396m_clk);
- clk_set_parent(pll1_sw_clk, step_clk);
- if (freq_hz > clk_get_rate(pll2_pfd2_396m_clk)) {
- clk_set_rate(pll1_sys_clk, new_freq * 1000);
+ if (of_machine_is_compatible("fsl,imx6ul")) {
+ /*
+* When changing pll1_sw_clk's parent to pll1_sys_clk,
+* CPU may run at higher than 528MHz, this will lead to
+* the system unstable if the voltage is lower than the
+* voltage of 528MHz, so lower the CPU frequency to one
+* half before changing CPU frequency.
+*/
+ clk_set_rate(arm_clk, (old_freq >> 1) * 1000);
clk_set_parent(pll1_sw_clk, pll1_sys_clk);
+ if (freq_hz > clk_get_rate(pll2_pfd2_396m_clk))
+ clk_set_parent(secondary_sel_clk, pll2_bus_clk);
+ else
+ clk_set_parent(secondary_sel_clk, pll2_pfd2_396m_clk);
+ clk_set_parent(step_clk, secondary_sel_clk);
+ clk_set_parent(pll1_sw_clk, step_clk);
+ } else {
+ clk_set_parent(step_clk, pll2_pfd2_396m_clk);
+ clk_set_parent(pll1_sw_clk, step_clk);
+ if (freq_hz > clk_get_rate(pll2_pfd2_396m_clk)) {
+ clk_set_rate(pll1_sys_clk, new_freq * 1000);
+ clk_set_parent(pll1_sw_clk, pll1_sys_clk);
+ }
}
/* Ensure the arm clock divider is what we expect */
@@ -186,6 +210,16 @@ static int imx6q_cpufreq_probe(struct platform_device
*pdev)
goto put_clk;
}
+ if (of_machine_is_compatible("fsl,imx6ul")) {
+ pll2_bus_clk = clk_get(cpu_dev, "pll2_bus");
+ secondary_sel_clk = clk_get(cpu_dev, "secondary_sel");
+ if (IS_ERR(pll2_bus_clk) || IS_ERR(secondary_sel_clk)) {
+ dev_err(cpu_dev, "failed to get clocks specific to
imx6ul\n");
+ ret = -ENOENT;
+ goto put_clk;
+ }
+ }
+
arm_reg = regulator_get(cpu_dev, "arm");
pu_reg = regulator_get_optional(cpu_dev, "pu");
soc_reg = regulator_get(cpu_dev, "soc");
@@ -331,6 +365,10 @@ put_clk:
clk_put(step_clk);
if (!IS_ERR(pll2_pfd2_396m_clk))
clk_put(pll2_pfd2_396m_clk);
+ if (!IS_ERR(pll2_bus_clk))
+ clk_put(pll2_bus_clk);
+ if (!IS_ERR(secondary_sel_clk))
+ clk_put(secondary_sel_clk);
of_node_put(np);
return ret;
}
@@ -350,6 +388,8 @@ static int imx6q_cpufreq_remove(struct platform_device
*pdev)
clk_put(pll1_sw_clk);
clk_put(step_clk);
clk_put(pll2_pfd2_396m_clk);
+ clk_put(pll2_bus_clk);
+ clk_put(secondary_sel_clk);
return 0;
}
--
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 V4 1/4] kvm: factor out core eventfd assign/deassign logic
On Fri, 11 Sep 2015 11:17:34 +0800
Jason Wang wrote:
> This patch factors out core eventfd assign/deassign logic and leave
> the argument checking and bus index selection to callers.
>
> Cc: Gleb Natapov
> Cc: Paolo Bonzini
> Signed-off-by: Jason Wang
> ---
> virt/kvm/eventfd.c | 83
> --
> 1 file changed, 49 insertions(+), 34 deletions(-)
>
> diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
> index 9ff4193..163258d 100644
> --- a/virt/kvm/eventfd.c
> +++ b/virt/kvm/eventfd.c
> @@ -771,40 +771,14 @@ static enum kvm_bus ioeventfd_bus_from_flags(__u32
> flags)
> return KVM_MMIO_BUS;
> }
>
> -static int
> -kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
> +static int kvm_assign_ioeventfd_idx(struct kvm *kvm,
> + enum kvm_bus bus_idx,
> + struct kvm_ioeventfd *args)
> {
> - enum kvm_bus bus_idx;
> - struct _ioeventfd*p;
> - struct eventfd_ctx *eventfd;
> - int ret;
> -
> - bus_idx = ioeventfd_bus_from_flags(args->flags);
> - /* must be natural-word sized, or 0 to ignore length */
> - switch (args->len) {
> - case 0:
> - case 1:
> - case 2:
> - case 4:
> - case 8:
> - break;
> - default:
> - return -EINVAL;
> - }
>
> - /* check for range overflow */
> - if (args->addr + args->len < args->addr)
> - return -EINVAL;
> -
> - /* check for extra flags that we don't understand */
> - if (args->flags & ~KVM_IOEVENTFD_VALID_FLAG_MASK)
> - return -EINVAL;
> -
> - /* ioeventfd with no length can't be combined with DATAMATCH */
> - if (!args->len &&
> - args->flags & (KVM_IOEVENTFD_FLAG_PIO |
> -KVM_IOEVENTFD_FLAG_DATAMATCH))
> - return -EINVAL;
> + struct eventfd_ctx *eventfd;
> + struct _ioeventfd *p;
> + int ret;
>
> eventfd = eventfd_ctx_fdget(args->fd);
> if (IS_ERR(eventfd))
> @@ -873,14 +847,48 @@ fail:
> }
>
> static int
> -kvm_deassign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
> +kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
You'll move this function to below the deassign function in patch 2.
Maybe do it already here?
> {
> enum kvm_bus bus_idx;
> +
> + bus_idx = ioeventfd_bus_from_flags(args->flags);
> + /* must be natural-word sized, or 0 to ignore length */
> + switch (args->len) {
> + case 0:
> + case 1:
> + case 2:
> + case 4:
> + case 8:
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + /* check for range overflow */
> + if (args->addr + args->len < args->addr)
> + return -EINVAL;
> +
> + /* check for extra flags that we don't understand */
> + if (args->flags & ~KVM_IOEVENTFD_VALID_FLAG_MASK)
> + return -EINVAL;
> +
> + /* ioeventfd with no length can't be combined with DATAMATCH */
> + if (!args->len &&
> + args->flags & (KVM_IOEVENTFD_FLAG_PIO |
> +KVM_IOEVENTFD_FLAG_DATAMATCH))
> + return -EINVAL;
> +
> + return kvm_assign_ioeventfd_idx(kvm, bus_idx, args);
> +}
> +
> +static int
> +kvm_deassign_ioeventfd_idx(struct kvm *kvm, enum kvm_bus bus_idx,
> +struct kvm_ioeventfd *args)
While this file uses newline before function name quite often, putting
it on the same line seems more common - don't know which one the
maintainers prefer.
> +{
> struct _ioeventfd*p, *tmp;
> struct eventfd_ctx *eventfd;
> int ret = -ENOENT;
>
> - bus_idx = ioeventfd_bus_from_flags(args->flags);
> eventfd = eventfd_ctx_fdget(args->fd);
> if (IS_ERR(eventfd))
> return PTR_ERR(eventfd);
> @@ -918,6 +926,13 @@ kvm_deassign_ioeventfd(struct kvm *kvm, struct
> kvm_ioeventfd *args)
> return ret;
> }
>
> +static int kvm_deassign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd
> *args)
> +{
> + enum kvm_bus bus_idx = ioeventfd_bus_from_flags(args->flags);
> +
> + return kvm_deassign_ioeventfd_idx(kvm, bus_idx, args);
> +}
> +
> int
> kvm_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
> {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: exynos_defconfig: Disable simplefb support
Hello Krzysztof,
On 09/11/2015 09:16 AM, Krzysztof Kozlowski wrote:
> On 11.09.2015 16:07, Javier Martinez Canillas wrote:
>> Hello Krzysztof,
>>
>> On 09/11/2015 07:01 AM, Krzysztof Kozlowski wrote:
>>> On 10.09.2015 22:42, Javier Martinez Canillas wrote:
The simplefb driver allows the kernel to render on a pre-allocated
buffer that's been initialized by firmware before the kernel boots.
This option was enabled to have display working on the Exynos5250
Snow Chromebook by commit da9d0fbf5e9a ("ARM: exynos: defconfig
update") since proper DRM/KMS support did not exist at that time.
But now that the Exynos DRM driver has support for this hardware,
there is no need to have simplefb enabled. In fact, if a user has
a u-boot that injects the simplefb dev node to the FDT before pass
it to the kernel, display won't be properly initialized and only a
blank screen will be shown since there isn't a proper handoff from
the simplefb driver to the Exynos DRM driver.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/configs/exynos_defconfig | 1 -
1 file changed, 1 deletion(-)
>>>
>>> Seems logical. None of the boards use simple-framebuffer compatible
>>> anyway. I understand that on Snow simplefb was needed along with change
>>> in Uboot like this one:
>>> https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/refs/changes/58/49358/2
>>>
>>
>> Exactly but you won't see the dev node with the "simple-framebuffer"
>> compatible string in the DTS since is the bootloader that adds this
>> device node to the FDT before passing it to the kernel.
>>
>> The bootloader shouldn't mangle the FDT (with the exception of the
>> memory and choosen/bootargs nodes) but simplefb is just a hack to
>> re-use the display HW initialization made by the bootloader.
>>
>>> and now none of Exynos boards use simplefb anymore?
>>>
>>
>> Yes, there are no other Exynos boards using simplefb besides Snow
>> that I'm aware of but since Exynos DRM is working well on this board
>> from v4.0, there is no need for it anymore.
>
> OK,
> Reviewed-by: Krzysztof Kozlowski
>
Thanks!
>>
>> In fact, as explained in the commit message, it could do more harm
>> than good since users that are still booting with a u-boot that adds
>> the simplefb device node, only get a blank screen since the simplefb
>> driver is probed, creates a console and later the Exynos DRM probes
>> and re-initializes the HW creating its own console, causing this issue.
>>
>> I got several reports of users that says that mainline stop booting for
>> them but is just that they didn't get display working. Disabling simplefb
>> makes display to work again so maybe this is even -rc material and should
>> go to stable # v4.0+
>
> You know, it is only a defconfig. The issue is there regardless of
> change in defconfig. I am not convinced that defconfig problems are
> worth backporting. multi_v7 has it enabled anyway.
>
Yes, that's why I said "maybe" :)
> Maybe the EXYNOS_DRM should have some anti-dependency on SIMPLE_FB? But
hrmm I don't know, I think this issue happens with any DRM driver. Hopefully
there should be soon a nice hand off from simplefb to DRM drivers like early
console does to the real console drivers for UARTs.
> on the other hand the issue is actually caused by hacks in bootloader...
>
Yeah and in fact this does not happen with the stock bootloader that comes
shipped on these devices, is with a special build that has this hack enabled.
>
> Best regards,
> Krzysztof
>
>
Thanks a lot for your feedback.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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/4] kvm: fix double free for fast mmio eventfd
On Fri, 11 Sep 2015 11:17:35 +0800
Jason Wang wrote:
> We register wildcard mmio eventfd on two buses, one for KVM_MMIO_BUS
> and another is KVM_FAST_MMIO_BUS but with a single iodev
> instance. This will lead an issue: kvm_io_bus_destroy() knows nothing
> about the devices on two buses points to a single dev. Which will lead
s/points/pointing/
> double free[1] during exit. Fixing this by using allocate two
s/using allocate/allocating/
> instances of iodevs then register one on KVM_MMIO_BUS and another on
> KVM_FAST_MMIO_BUS.
>
(...)
> @@ -929,8 +878,66 @@ kvm_deassign_ioeventfd_idx(struct kvm *kvm, enum kvm_bus
> bus_idx,
> static int kvm_deassign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd
> *args)
> {
> enum kvm_bus bus_idx = ioeventfd_bus_from_flags(args->flags);
> + int ret = kvm_deassign_ioeventfd_idx(kvm, bus_idx, args);
> +
> + if (!args->len)
> + kvm_deassign_ioeventfd_idx(kvm, KVM_FAST_MMIO_BUS, args);
I think it would be good to explicitly check for bus_idx ==
KVM_MMIO_BUS here.
> +
> + return ret;
> +}
>
> - return kvm_deassign_ioeventfd_idx(kvm, bus_idx, args);
> +static int
> +kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
> +{
> + enum kvm_bus bus_idx;
> + int ret;
> +
> + bus_idx = ioeventfd_bus_from_flags(args->flags);
> + /* must be natural-word sized, or 0 to ignore length */
> + switch (args->len) {
> + case 0:
> + case 1:
> + case 2:
> + case 4:
> + case 8:
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + /* check for range overflow */
> + if (args->addr + args->len < args->addr)
> + return -EINVAL;
> +
> + /* check for extra flags that we don't understand */
> + if (args->flags & ~KVM_IOEVENTFD_VALID_FLAG_MASK)
> + return -EINVAL;
> +
> + /* ioeventfd with no length can't be combined with DATAMATCH */
> + if (!args->len &&
> + args->flags & (KVM_IOEVENTFD_FLAG_PIO |
> +KVM_IOEVENTFD_FLAG_DATAMATCH))
> + return -EINVAL;
> +
> + ret = kvm_assign_ioeventfd_idx(kvm, bus_idx, args);
> + if (ret)
> + goto fail;
> +
> + /* When length is ignored, MMIO is also put on a separate bus, for
> + * faster lookups.
> + */
> + if (!args->len && !(args->flags & KVM_IOEVENTFD_FLAG_PIO)) {
Dito on a positive check for bus_idx == KVM_MMIO_BUS.
> + ret = kvm_assign_ioeventfd_idx(kvm, KVM_FAST_MMIO_BUS, args);
> + if (ret < 0)
> + goto fast_fail;
> + }
> +
> + return 0;
> +
> +fast_fail:
> + kvm_deassign_ioeventfd(kvm, args);
Shouldn't you use kvm_deassign_ioeventfd(kvm, bus_idx, args) here?
> +fail:
> + return ret;
> }
>
> int
--
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 5/6] sched/fair: Get rid of scaling utilization by capacity_orig
Hi Morten,
On Tue, Sep 08, 2015 at 05:53:31PM +0100, Morten Rasmussen wrote:
> On Tue, Sep 08, 2015 at 03:31:58PM +0100, Morten Rasmussen wrote:
> > On Tue, Sep 08, 2015 at 02:52:05PM +0200, Peter Zijlstra wrote:
> > >
> > > Something like teh below..
> > >
> > > Another thing to ponder; the downside of scaled_delta_w is that its
> > > fairly likely delta is small and you loose all bits, whereas the weight
> > > is likely to be large can could loose a fwe bits without issue.
> >
> > That issue applies both to load and util.
> >
> > >
> > > That is, in fixed point scaling like this, you want to start with the
> > > biggest numbers, not the smallest, otherwise you loose too much.
> > >
> > > The flip side is of course that now you can share a multiplcation.
> >
> > But if we apply the scaling to the weight instead of time, we would only
> > have to apply it once and not three times like it is now? So maybe we
> > can end up with almost the same number of multiplications.
> >
> > We might be loosing bits for low priority task running on cpus at a low
> > frequency though.
>
> Something like the below. We should be saving one multiplication.
>
> --- 8< ---
>
> From: Morten Rasmussen
> Date: Tue, 8 Sep 2015 17:15:40 +0100
> Subject: [PATCH] sched/fair: Scale load/util contribution rather than time
>
> When updating load/util tracking the time delta might be very small (1)
> in many cases, scaling it futher down with frequency and cpu invariance
> scaling might cause us to loose precision. Instead of scaling time we
> can scale the weight of the task for load and the capacity for
> utilization. Both weight (>=15) and capacity should be significantly
> bigger in most cases. Low priority tasks might still suffer a bit but
> worst should be improved, as weight is at least 15 before invariance
> scaling.
>
> Signed-off-by: Morten Rasmussen
> ---
> kernel/sched/fair.c | 38 +++---
> 1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 9301291..d5ee72a 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -2519,8 +2519,6 @@ static u32 __compute_runnable_contrib(u64 n)
> #error "load tracking assumes 2^10 as unit"
> #endif
>
> -#define cap_scale(v, s) ((v)*(s) >> SCHED_CAPACITY_SHIFT)
> -
> /*
> * We can represent the historical contribution to runnable average as the
> * coefficients of a geometric series. To do this we sub-divide our runnable
> @@ -2553,10 +2551,10 @@ static __always_inline int
> __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
> unsigned long weight, int running, struct cfs_rq *cfs_rq)
> {
> - u64 delta, scaled_delta, periods;
> + u64 delta, periods;
> u32 contrib;
> - unsigned int delta_w, scaled_delta_w, decayed = 0;
> - unsigned long scale_freq, scale_cpu;
> + unsigned int delta_w, decayed = 0;
> + unsigned long scaled_weight = 0, scale_freq, scale_freq_cpu = 0;
>
> delta = now - sa->last_update_time;
> /*
> @@ -2577,8 +2575,13 @@ __update_load_avg(u64 now, int cpu, struct sched_avg
> *sa,
> return 0;
> sa->last_update_time = now;
>
> - scale_freq = arch_scale_freq_capacity(NULL, cpu);
> - scale_cpu = arch_scale_cpu_capacity(NULL, cpu);
> + if (weight || running)
> + scale_freq = arch_scale_freq_capacity(NULL, cpu);
> + if (weight)
> + scaled_weight = weight * scale_freq >> SCHED_CAPACITY_SHIFT;
> + if (running)
> + scale_freq_cpu = scale_freq * arch_scale_cpu_capacity(NULL, cpu)
> + >> SCHED_CAPACITY_SHIFT;
maybe below question is stupid :)
Why not calculate the scaled_weight depend on cpu's capacity as well?
So like: scaled_weight = weight * scale_freq_cpu.
> /* delta_w is the amount already accumulated against our next period */
> delta_w = sa->period_contrib;
> @@ -2594,16 +2597,15 @@ __update_load_avg(u64 now, int cpu, struct sched_avg
> *sa,
>* period and accrue it.
>*/
> delta_w = 1024 - delta_w;
> - scaled_delta_w = cap_scale(delta_w, scale_freq);
> if (weight) {
> - sa->load_sum += weight * scaled_delta_w;
> + sa->load_sum += scaled_weight * delta_w;
> if (cfs_rq) {
> cfs_rq->runnable_load_sum +=
> - weight * scaled_delta_w;
> + scaled_weight * delta_w;
> }
> }
> if (running)
> - sa->util_sum += scaled_delta_w * scale_cpu;
> + sa->util_sum += delta_w * scale_freq_cpu;
>
> delta -= delta_w;
>
> @@ -2620,25 +2622,23 @@ __update_load_avg(u64 now, int cpu, struct sched_avg
> *sa,
>
>
Re: [PATCH RESEND 2/5] extcon: arizona: Add support for new ADC value headphone detect
On 2015년 09월 09일 17:34, Charles Keepax wrote: > Newer devices give users the option to make the 3/4 pole jack > determination using a software comparison rather than a hardware one. > This patch adds support for this functionality. > > Signed-off-by: Charles Keepax > --- > drivers/extcon/extcon-arizona.c | 67 +++--- > 1 files changed, 61 insertions(+), 6 deletions(-) > > diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c > index 4b9f09c..f372156 100644 > --- a/drivers/extcon/extcon-arizona.c > +++ b/drivers/extcon/extcon-arizona.c Acked-by: Chanwoo Choi Thanks, Chanwoo Choi -- 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 4/5] extcon: arizona: Add support for general purpose switch
On 2015년 09월 09일 17:34, Charles Keepax wrote: > The switch is typically used in conjunction with the MICDET clamp in > order to suppress pops and clicks associated with jack insertion. > > Signed-off-by: Charles Keepax > --- > drivers/extcon/extcon-arizona.c |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) Acked-by: Chanwoo Choi Thanks, Chanwoo Choi -- 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 5/5] mfd: arizona: Update DT doc for new mic detection bindings
On 2015년 09월 09일 17:34, Charles Keepax wrote: > Signed-off-by: Charles Keepax > --- > Documentation/devicetree/bindings/mfd/arizona.txt | 21 > + > include/dt-bindings/mfd/arizona.h |5 + > 2 files changed, 26 insertions(+), 0 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt > b/Documentation/devicetree/bindings/mfd/arizona.txt > index a8fee60..b98a11b 100644 > --- a/Documentation/devicetree/bindings/mfd/arizona.txt > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt > @@ -73,6 +73,27 @@ Optional properties: > If this node is not mentioned or if the value is unknown, then > headphone detection mode is set to HPDETL. > > + - wlf,micd-software-compare : Use a software comparison to determine mic > +presence > + - wlf,micd-detect-debounce : Additional software microphone detection > +debounce specified in milliseconds. > + - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset > +polarity if one exists. > + - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to > +performing microphone detection, specified as per the > ARIZONA_MICD_TIME_XXX > +defines. > + - wlf,micd-rate : Delay between successive microphone detection > measurements, > +specified as per the ARIZONA_MICD_TIME_XXX defines. > + - wlf,micd-dbtime : Microphone detection hardware debounces specified as > the > +number of measurements to take, valid values being 2 and 4. > + - wlf,micd-timeout : Timeout for microphone detection, specified in > +milliseconds. > + - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone > +detection. > + > + - wlf,gpsw : Settings for the general purpose switch, set as one of the > +ARIZONA_GPSW_XXX defines. > + >- DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified > if > they are being externally supplied. As covered in > Documentation/devicetree/bindings/regulator/regulator.txt > diff --git a/include/dt-bindings/mfd/arizona.h > b/include/dt-bindings/mfd/arizona.h > index c40f665..dedf46f 100644 > --- a/include/dt-bindings/mfd/arizona.h > +++ b/include/dt-bindings/mfd/arizona.h > @@ -110,4 +110,9 @@ > #define ARIZONA_ACCDET_MODE_HPM 4 > #define ARIZONA_ACCDET_MODE_ADC 7 > > +#define ARIZONA_GPSW_OPEN 0 > +#define ARIZONA_GPSW_CLOSED 1 > +#define ARIZONA_GPSW_CLAMP_ENABLED 2 > +#define ARIZONA_GPSW_CLAMP_DISABLED 3 > + > #endif > Reviewed-by: Chanwoo Choi You may need the ack message by DT maintainer. Thanks, Chanwoo Choi -- 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] arm64: dma-mapping: check whether cma area is initialized or not
If CMA is turned on and CMA size is set to zero, kernel should
behave as if CMA was not enabled at compile time.
Every dma allocation should check existence of cma area
before requesting memory.
Arm has done this by commit e464ef16c4f0 ("arm: dma-mapping: add
checking cma area initialized"), also do this for arm64.
Signed-off-by: Jisheng Zhang
---
arch/arm64/mm/dma-mapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 0bcc4bc..99224dc 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -100,7 +100,7 @@ static void *__dma_alloc_coherent(struct device *dev,
size_t size,
if (IS_ENABLED(CONFIG_ZONE_DMA) &&
dev->coherent_dma_mask <= DMA_BIT_MASK(32))
flags |= GFP_DMA;
- if (IS_ENABLED(CONFIG_DMA_CMA) && (flags & __GFP_WAIT)) {
+ if (dev_get_cma_area(dev) && (flags & __GFP_WAIT)) {
struct page *page;
void *addr;
--
2.5.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 RESEND 1/5] mfd: arizona: Add registers for ADC microphone detection
Hi Lee, Charles,
I make the temporary branch[1] and then apply patch1-patch4 without patch5
because of patch5 may need the ack message by DT maintainer. If Lee want to
make the immutable branch and send the pull request, I'll make the immutable
branch based on Linux-4.3-rcX and send it to MFD maintainer (Lee Jones).
[1] branch name : extcon-next-v4.4-for-arizona
-
git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-next-v4.4-for-arizona
I need the your opinion.
Thanks,
Chanwoo Choi
On 2015년 09월 09일 17:34, Charles Keepax wrote:
> The newer devices support using a software comparison to determine
> whether a 3/4 pole jack is present. Add the registers necessary for
> this.
>
> Signed-off-by: Charles Keepax
> Acked-by: Lee Jones
> ---
> drivers/mfd/wm5110-tables.c |2 ++
> include/dt-bindings/mfd/arizona.h |2 ++
> include/linux/mfd/arizona/pdata.h |3 +++
> include/linux/mfd/arizona/registers.h | 17 ++---
> 4 files changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mfd/wm5110-tables.c b/drivers/mfd/wm5110-tables.c
> index 12cad94..dd27872 100644
> --- a/drivers/mfd/wm5110-tables.c
> +++ b/drivers/mfd/wm5110-tables.c
> @@ -1807,6 +1807,7 @@ static bool wm5110_readable_register(struct device
> *dev, unsigned int reg)
> case ARIZONA_MIC_DETECT_1:
> case ARIZONA_MIC_DETECT_2:
> case ARIZONA_MIC_DETECT_3:
> + case ARIZONA_MIC_DETECT_4:
> case ARIZONA_MIC_DETECT_LEVEL_1:
> case ARIZONA_MIC_DETECT_LEVEL_2:
> case ARIZONA_MIC_DETECT_LEVEL_3:
> @@ -2843,6 +2844,7 @@ static bool wm5110_volatile_register(struct device
> *dev, unsigned int reg)
> case ARIZONA_ASYNC_SAMPLE_RATE_1_STATUS:
> case ARIZONA_ASYNC_SAMPLE_RATE_2_STATUS:
> case ARIZONA_MIC_DETECT_3:
> + case ARIZONA_MIC_DETECT_4:
> case ARIZONA_HP_CTRL_1L:
> case ARIZONA_HP_CTRL_1R:
> case ARIZONA_HEADPHONE_DETECT_2:
> diff --git a/include/dt-bindings/mfd/arizona.h
> b/include/dt-bindings/mfd/arizona.h
> index 7b2000c..c40f665 100644
> --- a/include/dt-bindings/mfd/arizona.h
> +++ b/include/dt-bindings/mfd/arizona.h
> @@ -107,5 +107,7 @@
> #define ARIZONA_ACCDET_MODE_MIC 0
> #define ARIZONA_ACCDET_MODE_HPL 1
> #define ARIZONA_ACCDET_MODE_HPR 2
> +#define ARIZONA_ACCDET_MODE_HPM 4
> +#define ARIZONA_ACCDET_MODE_ADC 7
>
> #endif
> diff --git a/include/linux/mfd/arizona/pdata.h
> b/include/linux/mfd/arizona/pdata.h
> index 43db4fa..f030a32 100644
> --- a/include/linux/mfd/arizona/pdata.h
> +++ b/include/linux/mfd/arizona/pdata.h
> @@ -124,6 +124,9 @@ struct arizona_pdata {
> /** Channel to use for headphone detection */
> unsigned int hpdet_channel;
>
> + /** Use software comparison to determine mic presence */
> + bool micd_software_compare;
> +
> /** Extra debounce timeout used during initial mic detection (ms) */
> int micd_detect_debounce;
>
> diff --git a/include/linux/mfd/arizona/registers.h
> b/include/linux/mfd/arizona/registers.h
> index 3499d36..3f3bb2b 100644
> --- a/include/linux/mfd/arizona/registers.h
> +++ b/include/linux/mfd/arizona/registers.h
> @@ -139,6 +139,7 @@
> #define ARIZONA_MIC_DETECT_LEVEL_20x2A7
> #define ARIZONA_MIC_DETECT_LEVEL_30x2A8
> #define ARIZONA_MIC_DETECT_LEVEL_40x2A9
> +#define ARIZONA_MIC_DETECT_4 0x2AB
> #define ARIZONA_MIC_NOISE_MIX_CONTROL_1 0x2C3
> #define ARIZONA_ISOLATION_CONTROL0x2CB
> #define ARIZONA_JACK_DETECT_ANALOGUE 0x2D3
> @@ -2301,9 +2302,9 @@
> #define ARIZONA_ACCDET_SRC_MASK 0x2000 /* ACCDET_SRC */
> #define ARIZONA_ACCDET_SRC_SHIFT 13 /* ACCDET_SRC */
> #define ARIZONA_ACCDET_SRC_WIDTH 1 /* ACCDET_SRC */
> -#define ARIZONA_ACCDET_MODE_MASK 0x0003 /* ACCDET_MODE -
> [1:0] */
> -#define ARIZONA_ACCDET_MODE_SHIFT 0 /* ACCDET_MODE -
> [1:0] */
> -#define ARIZONA_ACCDET_MODE_WIDTH 2 /* ACCDET_MODE -
> [1:0] */
> +#define ARIZONA_ACCDET_MODE_MASK 0x0007 /* ACCDET_MODE -
> [2:0] */
> +#define ARIZONA_ACCDET_MODE_SHIFT 0 /* ACCDET_MODE -
> [2:0] */
> +#define ARIZONA_ACCDET_MODE_WIDTH 3 /* ACCDET_MODE -
> [2:0] */
>
> /*
> * R667 (0x29B) - Headphone Detect 1
> @@ -2413,6 +2414,16 @@
> #define ARIZONA_MICD_STS_WIDTH1 /* MICD_STS */
>
> /*
> + * R683 (0x2AB) - Mic Detect 4
> + */
> +#define ARIZONA_MICDET_ADCVAL_DIFF_MASK 0xFF00 /*
> MICDET_ADCVAL_DIFF - [15:8] */
> +#define ARIZONA_MICDET_ADCVAL_DIFF_SHIFT 8 /*
> MICDET_ADCVAL_DIFF - [15:8] */
> +#define ARIZONA_MICDET_ADCVAL_DIFF_WIDTH 8 /*
> MICDET_ADCVAL_DIFF - [15:8] */
> +#define ARIZONA_MICDET_ADCVAL_MASK 0x007F /* MICDET_ADCVAL -
> [15:8] */
> +#define ARIZONA_MICDET_ADCVAL_SH
Re: [PATCH 3/6] extcon: arizona: Ignore jd_invert for MICD_CLAMP_STS
On 2015년 09월 10일 20:41, Charles Keepax wrote:
> From: Nariman Poushin
>
> The polarity of MICD_CLAMP_STS does not change when different clamp
> modes are used, this patch corrects this issue.
>
> Signed-off-by: Nariman Poushin
> Signed-off-by: Charles Keepax
> ---
> drivers/extcon/extcon-arizona.c |5 +
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index 7bfaacd..6d030a0 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -1059,10 +1059,7 @@ static irqreturn_t arizona_jackdet(int irq, void *data)
>
> if (arizona->pdata.jd_gpio5) {
> mask = ARIZONA_MICD_CLAMP_STS;
> - if (arizona->pdata.jd_invert)
> - present = ARIZONA_MICD_CLAMP_STS;
> - else
> - present = 0;
> + present = 0;
> } else {
> mask = ARIZONA_JD1_STS;
> if (arizona->pdata.jd_invert)
>
Acked-by: Chanwoo Choi
Thanks,
Chanwoo Choi
--
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/6] extcon: arizona: Add device binding for jack detect polarity inversion
On 2015년 09월 10일 20:41, Charles Keepax wrote: > Signed-off-by: Charles Keepax > --- > drivers/extcon/extcon-arizona.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c > index 6d030a0..34b5a3b 100644 > --- a/drivers/extcon/extcon-arizona.c > +++ b/drivers/extcon/extcon-arizona.c > @@ -1228,6 +1228,9 @@ static int arizona_extcon_device_get_pdata(struct > arizona *arizona) > pdata->micd_software_compare = device_property_read_bool(arizona->dev, > "wlf,micd-software-compare"); > > + pdata->jd_invert = device_property_read_bool(arizona->dev, > + "wlf,jd-invert"); > + > device_property_read_u32(arizona->dev, "wlf,gpsw", &pdata->gpsw); > > return 0; > I'd like you to add the patch description. If you add the description, you can add the my ack messageL Acked-by: Chanwoo Choi Thanks, Chanwoo Choi -- 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] cpufreq: imx: update the clock switch flow to support imx6ul
On 11-09-15, 23:41, Bai Ping wrote:
> + if (of_machine_is_compatible("fsl,imx6ul")) {
> + pll2_bus_clk = clk_get(cpu_dev, "pll2_bus");
> + secondary_sel_clk = clk_get(cpu_dev, "secondary_sel");
> + if (IS_ERR(pll2_bus_clk) || IS_ERR(secondary_sel_clk)) {
> + dev_err(cpu_dev, "failed to get clocks specific to
> imx6ul\n");
> + ret = -ENOENT;
> + goto put_clk;
> + }
> + }
> +
> arm_reg = regulator_get(cpu_dev, "arm");
> pu_reg = regulator_get_optional(cpu_dev, "pu");
> soc_reg = regulator_get(cpu_dev, "soc");
> @@ -331,6 +365,10 @@ put_clk:
> clk_put(step_clk);
> if (!IS_ERR(pll2_pfd2_396m_clk))
> clk_put(pll2_pfd2_396m_clk);
> + if (!IS_ERR(pll2_bus_clk))
> + clk_put(pll2_bus_clk);
> + if (!IS_ERR(secondary_sel_clk))
> + clk_put(secondary_sel_clk);
> of_node_put(np);
> return ret;
> }
As part of good coding practices, you should free resources in the
reverse order to which they were allocated. The clocks don't follow
that, but its not a problem with just your patch. That's how it is
present today. Maybe you can write another patch to fix that.
Acked-by: Viresh Kumar
--
viresh
--
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 5/6] extcon: arizona: Add device binding for second jack detect pin on GPIO5
On 2015년 09월 10일 20:41, Charles Keepax wrote: > Signed-off-by: Charles Keepax > --- > drivers/extcon/extcon-arizona.c |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c > index 34b5a3b..5fbe893 100644 > --- a/drivers/extcon/extcon-arizona.c > +++ b/drivers/extcon/extcon-arizona.c > @@ -1233,6 +1233,11 @@ static int arizona_extcon_device_get_pdata(struct > arizona *arizona) > > device_property_read_u32(arizona->dev, "wlf,gpsw", &pdata->gpsw); > > + pdata->jd_gpio5 = device_property_read_bool(arizona->dev, > + "wlf,use-jd-gpio"); > + pdata->jd_gpio5_nopull = device_property_read_bool(arizona->dev, > + "wlf,use-jd-gpio-nopull"); > + > return 0; > } > > I'd like you to add the patch description. If you add the description, you can add the my ack messageL Acked-by: Chanwoo Choi Thanks, Chanwoo Choi -- 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 6/6] mfd: arizona: Update DT binding documentation for jack detection
On 2015년 09월 10일 20:41, Charles Keepax wrote: > Add additional bindings for both inverting the polarity of the jack > detection pins and allowing the use of a second jack detection pin. Note > that the second jack detection pin is hard wired in the chip so can only > be enabled through the binding, rather than a pin being specified. > > Signed-off-by: Charles Keepax > --- > Documentation/devicetree/bindings/mfd/arizona.txt |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt > b/Documentation/devicetree/bindings/mfd/arizona.txt > index b98a11b..48bca6a 100644 > --- a/Documentation/devicetree/bindings/mfd/arizona.txt > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt > @@ -73,6 +73,12 @@ Optional properties: > If this node is not mentioned or if the value is unknown, then > headphone detection mode is set to HPDETL. > > + - wlf,use-jd-gpio : Use GPIO input alongwith JD1 for dual pin jack s/alongwith/along with > +detection. > + - wlf,use-jd-gpio-nopull : Internal pull on GPIO is disabled when used for > +jack detection. > + - wlf,jd-invert : Invert the polarity of the jack detection switch > + >- wlf,micd-software-compare : Use a software comparison to determine mic > presence >- wlf,micd-detect-debounce : Additional software microphone detection > If you fixes the minor typo, looks good to me. Reviewed-by: Chanwoo Choi Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/3] 1588 support for Zynq Ultrascale+ MPSoC
This series adds 1588 support in Cadence MACB driver for Zynq Ultrascale+ MPSoC This IP supports HW timestamping and this is accesible through extended BD. The first patch adds support for extended BD through a config option. Since this required the use two extra u32 variables in the macb_dma_desc structure, we opted for a static config option. The second patch adds support to access the timestamp in TX and RX paths, register to PTP framework and provide time and frequency adjustment. This was tested in two step mode using linuxptp. The TSU clock is expected to be provided through devicetree. Harini Katakam (3): net: macb: Add support for extended BD with a config option net: macb: Add support for 1588 for Zynq Ultrascale+ MPSoC devicetree: macb: Add optional property tsu-clk Documentation/devicetree/bindings/net/macb.txt |3 + drivers/net/ethernet/cadence/Kconfig |8 + drivers/net/ethernet/cadence/macb.c| 376 +++- drivers/net/ethernet/cadence/macb.h| 72 + 4 files changed, 451 insertions(+), 8 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/3] net: macb: Add support for extended BD with a config option
Cadence GEM supports extended buffer descriptors.
This patch adds a config option to enable use of extended BD.
This adds two extra words to the TX BD and RX BD by configuring the
necessary registers. Corresponding variables are added to the
macb_dma_desc structure.
Signed-off-by: Harini Katakam
---
drivers/net/ethernet/cadence/Kconfig |8
drivers/net/ethernet/cadence/macb.c |4
drivers/net/ethernet/cadence/macb.h |8
3 files changed, 20 insertions(+)
diff --git a/drivers/net/ethernet/cadence/Kconfig
b/drivers/net/ethernet/cadence/Kconfig
index f0bcb15..33e4198 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -31,4 +31,12 @@ config MACB
To compile this driver as a module, choose M here: the module
will be called macb.
+config MACB_EXT_BD
+ tristate "Cadence MACB/GEM extended buffer descriptor"
+ depends on HAS_DMA && MACB
+ ---help---
+ The Cadence MACB host supports use of extended buffer descriptor.
+ This option enables additon of two extra words to TX BD and RX BD.
+ These two extra words are currently used to obtain PTP timestamp.
+
endif # NET_CADENCE
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index 88c1e1a..bb2932c 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -1665,6 +1665,10 @@ static void macb_configure_dma(struct macb *bp)
dmacfg |= GEM_BIT(TXCOEN);
else
dmacfg &= ~GEM_BIT(TXCOEN);
+#ifdef CONFIG_MACB_EXT_BD
+ dmacfg |= GEM_BIT(RXBDEXT);
+ dmacfg |= GEM_BIT(TXBDEXT);
+#endif
netdev_dbg(bp->dev, "Cadence configure DMA with 0x%08x\n",
dmacfg);
gem_writel(bp, DMACFG, dmacfg);
diff --git a/drivers/net/ethernet/cadence/macb.h
b/drivers/net/ethernet/cadence/macb.h
index 6e1faea..58c9870 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -244,6 +244,10 @@
#define GEM_RXBS_SIZE 8
#define GEM_DDRP_OFFSET24 /* disc_when_no_ahb */
#define GEM_DDRP_SIZE 1
+#define GEM_RXBDEXT_OFFSET 28 /* Extended RX BD */
+#define GEM_RXBDEXT_SIZE 1
+#define GEM_TXBDEXT_OFFSET 29 /* Extended TX BD */
+#define GEM_TXBDEXT_SIZE 1
/* Bitfields in NSR */
@@ -466,6 +470,10 @@
struct macb_dma_desc {
u32 addr;
u32 ctrl;
+#ifdef CONFIG_MACB_EXT_BD
+ u32 tsl;
+ u32 tsh;
+#endif
};
/* DMA descriptor bitfields */
--
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 1/6] mfd: arizona: Add TST_CAP bits for headphone detection
Hi Charles, I recommend that you make the cover-letter patches on later. If you better to explain the patch description on cover-letter patch, we will understand what is this patch-set more easily. Thanks, Chanwoo Choi On 2015년 09월 10일 20:41, Charles Keepax wrote: > On Florida some additional settings are required to get accurate > measurements at the top end of the headphone detection range. This patch > adds the bits required for this. > > Signed-off-by: Charles Keepax > --- > drivers/mfd/wm5110-tables.c |2 ++ > include/linux/mfd/arizona/registers.h |8 > 2 files changed, 10 insertions(+), 0 deletions(-) > > diff --git a/drivers/mfd/wm5110-tables.c b/drivers/mfd/wm5110-tables.c > index acb3bb2..78032e8 100644 > --- a/drivers/mfd/wm5110-tables.c > +++ b/drivers/mfd/wm5110-tables.c > @@ -1908,6 +1908,7 @@ static bool wm5110_readable_register(struct device > *dev, unsigned int reg) > case ARIZONA_HP1_SHORT_CIRCUIT_CTRL: > case ARIZONA_HP2_SHORT_CIRCUIT_CTRL: > case ARIZONA_HP3_SHORT_CIRCUIT_CTRL: > + case ARIZONA_HP_TEST_CTRL_1: > case ARIZONA_AIF1_BCLK_CTRL: > case ARIZONA_AIF1_TX_PIN_CTRL: > case ARIZONA_AIF1_RX_PIN_CTRL: > @@ -2853,6 +2854,7 @@ static bool wm5110_volatile_register(struct device > *dev, unsigned int reg) > case ARIZONA_INPUT_ENABLES_STATUS: > case ARIZONA_OUTPUT_STATUS_1: > case ARIZONA_RAW_OUTPUT_STATUS_1: > + case ARIZONA_HP_TEST_CTRL_1: > case ARIZONA_SLIMBUS_RX_PORT_STATUS: > case ARIZONA_SLIMBUS_TX_PORT_STATUS: > case ARIZONA_INTERRUPT_STATUS_1: > diff --git a/include/linux/mfd/arizona/registers.h > b/include/linux/mfd/arizona/registers.h > index e96644c..fe1b5d0 100644 > --- a/include/linux/mfd/arizona/registers.h > +++ b/include/linux/mfd/arizona/registers.h > @@ -237,6 +237,7 @@ > #define ARIZONA_HP1_SHORT_CIRCUIT_CTRL 0x4A0 > #define ARIZONA_HP2_SHORT_CIRCUIT_CTRL 0x4A1 > #define ARIZONA_HP3_SHORT_CIRCUIT_CTRL 0x4A2 > +#define ARIZONA_HP_TEST_CTRL_1 0x4A4 > #define ARIZONA_SPK_CTRL_2 0x4B5 > #define ARIZONA_SPK_CTRL_3 0x4B6 > #define ARIZONA_DAC_COMP_1 0x4DC > @@ -3548,6 +3549,13 @@ > #define ARIZONA_HP3_SC_ENA_WIDTH 1 /* HP3_SC_ENA */ > > /* > + * R1188 (0x4A4) HP Test Ctrl 1 > + */ > +#define ARIZONA_HP1_TST_CAP_SEL_MASK 0x0003 /* HP1_TST_CAP_SEL > - [1:0] */ > +#define ARIZONA_HP1_TST_CAP_SEL_SHIFT 0 /* HP1_TST_CAP_SEL > - [1:0] */ > +#define ARIZONA_HP1_TST_CAP_SEL_WIDTH 2 /* HP1_TST_CAP_SEL > - [1:0] */ > + > +/* > * R1244 (0x4DC) - DAC comp 1 > */ > #define ARIZONA_OUT_COMP_COEFF_MASK 0x /* OUT_COMP_COEFF - > [15: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/
[RFC PATCH 2/3] net: macb: Add support for 1588 for Zynq Ultrascale+ MPSoC
Cadence GEM in Zynq Ultrascale+ MPSoC supports 1588 and provides a
102 bit time counter with 48 bits for seconds, 30 bits for nsecs and
24 bits for sub-nsecs. The timestamp is made available to the SW through
registers as well as (more precisely) through upper two words in
an extended BD.
This patch does the following:
- Adds MACB_CAPS_TSU in zynqmp_config.
- Registers to ptp clock framework (after checking for timestamp support in
IP and capability in config).
- TX BD and RX BD control registers are written to populate timestamp in
extended BD words.
- Timer initialization is done by writing time of day to the timer counter.
- ns increment register is programmed as NS_PER_SEC/TSU_CLK.
For a 24 bit subns precision, the subns increment equals
remainder of (NS_PER_SEC/TSU_CLK) * (2^24).
TSU (Time stamp unit) clock is obtained by the driver from devicetree.
- HW time stamp capabilities are advertised via ethtool and macb ioctl is
updated accordingly.
- For all PTP event frames, nanoseconds and the lower 5 bits of seconds are
obtained from the BD. This offers a precise timestamp. The upper bits
(which dont vary between consecutive packets) are obtained from the
TX/RX PTP event/PEER registers. The timestamp obtained thus is updated
in skb for upper layers to access.
- The drivers register functions with ptp to perform time and frequency
adjustment.
- Time adjustment is done by writing to the 1558_ADJUST register.
The controller will read the delta in this register and update the timer
counter register. Alternatively, for large time offset adjustments,
the driver reads the secs and nsecs counter values, adds/subtracts the
delta and updates the timer counter. In order to be as precise as possible,
nsecs counter is read again if secs has incremented during the counter read.
- Frequency adjustment is not directly supported by this IP.
addend is the initial value ns increment and similarly addendesub.
The ppb (parts per billion) provided is used as
ns_incr = addend +/- (ppb/rate).
Similarly the remainder of the above is used to populate subns increment.
In case the ppb requested is negative AND subns adjustment greater than
the addendsub, ns_incr is reduced by 1 and subns_incr is adjusted in
positive accordingly.
Signed-off-by: Harini Katakam :
---
drivers/net/ethernet/cadence/macb.c | 372 ++-
drivers/net/ethernet/cadence/macb.h | 64 ++
2 files changed, 428 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index bb2932c..b531008 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -30,6 +30,8 @@
#include
#include
#include
+#include
+#include
#include "macb.h"
@@ -56,6 +58,9 @@
#define GEM_MTU_MIN_SIZE 68
+#define GEM_TX_PTPHDR_OFFSET 42
+#define GEM_RX_PTPHDR_OFFSET 28
+
/*
* Graceful stop timeouts in us. We should allow up to
* 1 frame time (10 Mbits/s, full-duplex, ignoring collisions)
@@ -165,6 +170,9 @@ static void macb_set_hwaddr(struct macb *bp)
top = cpu_to_le16(*((u16 *)(bp->dev->dev_addr + 4)));
macb_or_gem_writel(bp, SA1T, top);
+ gem_writel(bp, RXPTPUNI, bottom);
+ gem_writel(bp, TXPTPUNI, bottom);
+
/* Clear unused address register sets */
macb_or_gem_writel(bp, SA2B, 0);
macb_or_gem_writel(bp, SA2T, 0);
@@ -653,6 +661,40 @@ static void macb_tx_error_task(struct work_struct *work)
spin_unlock_irqrestore(&bp->lock, flags);
}
+static inline void macb_handle_txtstamp(struct macb *bp, struct sk_buff *skb,
+ struct macb_dma_desc *desc)
+{
+ u32 ts_s, ts_ns;
+ u8 msg_type;
+
+ skb_copy_from_linear_data_offset(skb, GEM_TX_PTPHDR_OFFSET,
+&msg_type, 1);
+
+ /* Bit[32:6] of TS secs from register
+* Bit[5:0] of TS secs from BD
+* TS nano secs is available in BD
+*/
+ if (msg_type & 0x2) {
+ /* PTP Peer Event Frame packets */
+ ts_s = (gem_readl(bp, 1588PEERTXSEC) & GEM_SEC_MASK) |
+ ((desc->tsl >> GEM_TSL_SEC_RS) |
+ (desc->tsh << GEM_TSH_SEC_LS));
+ ts_ns = desc->tsl & GEM_TSL_NSEC_MASK;
+ } else {
+ /* PTP Event Frame packets */
+ ts_s = (gem_readl(bp, 1588TXSEC) & GEM_SEC_MASK) |
+ ((desc->tsl >> GEM_TSL_SEC_RS) |
+ (desc->tsh << GEM_TSH_SEC_LS));
+ ts_ns = desc->tsl & GEM_TSL_NSEC_MASK;
+ }
+
+ struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
+
+ memset(shhwtstamps, 0, sizeof(struct skb_shared_hwtstamps));
+ shhwtstamps->hwtstamp = ns_to_ktime((ts_s * NS_PER_SEC) + ts_ns);
+ skb_tstamp_tx(skb, skb_hwtstamps(skb));
+}
+
static void macb_tx_interrupt(struct macb_queue *queue
Re: [RFC] asm-generic/pci_iomap.h: make custom PCI BAR requirements explicit
On Tue, 08 Sep 2015 15:42:40 +0200 Arnd Bergmann wrote: > On Thursday 03 September 2015 03:44:15 Luis R. Rodriguez wrote: > > On Sun, Aug 30, 2015 at 09:30:26PM +0200, Arnd Bergmann wrote: > > > On Friday 28 August 2015 17:17:27 Luis R. Rodriguez wrote: > > > > While at it, as with the ioremap*() variants, since we have no clear > > > > semantics yet well defined provide a solution for them that returns > > > > NULL. This allows architectures to move forward by defining > > > > pci_ioremap*() > > > > variants without requiring immediate changes to all architectures. Each > > > > architecture then can implement their own solution as needed and > > > > when they get to it. > > > > > > Which architectures are you thinking about here? > > > > Really only S390 would benefit from this now. > > Ok > > > > > Build tested with allyesconfig on: > > > > > > > > * S390 > > > > * x86_64 > > > > > > > > Signed-off-by: Luis R. Rodriguez > > > > > > It's not really clear to me what the purpose of the patch is, is this > > > meant as a cleanup, or are you trying to avoid some real-life bugs > > > you ran into? > > > > Upon adding a new helper into CONFIG_PCI_IOMAP it was only through > > 0-day build testing that I found that I needed to add something for S390. > > This means we fix S390 reactively. With the asm-generic stuff in place > > to return NULL we don't need to do anything but a respective return > > NULL static inline, the moment that is done the author would know some > > architectures may not get support for the functionality they are adding. > > Without this we only find out reactively. > > Hmm, my gut feeling tells me that your approach won't solve the problem > in general. s390 PCI is just weird in many ways and it will occasionally > suffer from problems like this (as do other aspects of the s390 architecture > that are unlike the rest of the world). > > Maybe Martin and Heiko can comment on this, they may have a preference > from the s390 point of view. I do not see how the additional Kconfig ARCH_PCI_NON_DISJUNCTIVE and the #ifdef indirections help with anything. An extension to lib/pci_iomap.c now requires an extra inline function in include/asm-generic/pci_iomap.h which I am sure will be added blindly without any consideration what s390 needs. Actually the patch makes it worse as the new inline will cover things up. Instead of a zero day compile error we will be left with a silently broken extension. I prefer a compile error as it points out that there is a problem. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 3/3] devicetree: macb: Add optional property tsu-clk
Add TSU clock frequency to be used for 1588 support in macb driver.
Signed-off-by: Harini Katakam
---
Documentation/devicetree/bindings/net/macb.txt |3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/macb.txt
b/Documentation/devicetree/bindings/net/macb.txt
index b5d7976..f7c0ea8 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -19,6 +19,9 @@ Required properties:
Optional elements: 'tx_clk'
- clocks: Phandles to input clocks.
+Optional properties:
+- tsu-clk: Time stamp unit clock frequency used.
+
Examples:
macb0: ethernet@fffc4000 {
--
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 V4 0/4] Fast MMIO eventfd fixes
On Fri, Sep 11, 2015 at 11:17:33AM +0800, Jason Wang wrote: > Hi: > > This series fixes two issues of fast mmio eventfd: > > 1) A single iodev instance were registerd on two buses: KVM_MMIO_BUS >and KVM_FAST_MMIO_BUS. This will cause double in >ioeventfd_destructor() > 2) A zero length iodev on KVM_MMIO_BUS will never be found but >kvm_io_bus_cmp(). This will lead e.g the eventfd will be trapped by >qemu instead of host. > > 1 is fixed by allocating two instances of iodev. 2 is fixed by ignore > the actual length if the length of iodev is zero in kvm_io_bus_cmp(). > > Please review. I think we should add a capability for fast mmio. This way, userspace can avoid crashing buggy kernels. > Changes from V3: > > - Don't do search on two buses when trying to do write on > KVM_MMIO_BUS. This fixes a small regression found by vmexit.flat. > - Since we don't do search on two buses, change kvm_io_bus_cmp() to > let it can find zero length iodevs. > - Fix the unnecessary lines in tracepoint patch. > > Changes from V2: > - Tweak styles and comment suggested by Cornelia. > > Changes from v1: > - change ioeventfd_bus_from_flags() to return KVM_FAST_MMIO_BUS when > needed to save lots of unnecessary changes. > > Jason Wang (4): > kvm: factor out core eventfd assign/deassign logic > kvm: fix double free for fast mmio eventfd > kvm: fix zero length mmio searching > kvm: add tracepoint for fast mmio > > arch/x86/kvm/trace.h | 18 > arch/x86/kvm/vmx.c | 1 + > arch/x86/kvm/x86.c | 1 + > virt/kvm/eventfd.c | 124 > ++- > virt/kvm/kvm_main.c | 4 +- > 5 files changed, 96 insertions(+), 52 deletions(-) > > -- > 2.1.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/
cpufreq: mediatek: allow modular build
The newly merged cpufreq-mt8173 driver breaks the ARM allmodconfig
build because of a dependency on the cpu-cooling infrastructure that
may be built as a loadable module:
drivers/built-in.o: In function `mtk_cpufreq_ready':
binder.c:(.text+0x324c8c): undefined reference to `of_cpufreq_cooling_register'
drivers/built-in.o: In function `mtk_cpufreq_exit':
binder.c:(.text+0x324ea0): undefined reference to `cpufreq_cooling_unregister'
This works around the issue by allowing this driver to be built
as a module as well, and adding a dependency on THERMAL that prevents
it from being built-in when the cpu-cooling driver is a module.
This is not perfect because there is still a case where THERMAL=m
and CPU_COOLING=n that should allow us to have this driver built-in
as well, but I decided to follow existing practice in other drivers
here, and that case seems irrelevant in practice.
Signed-off-by: Arnd Bergmann
---
I have not checked if someone else has already sent a patch for this,
just ignore mine if the issue has been fixed already.
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 77aa34eae92c..28844bdf026d 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -131,8 +131,8 @@ config ARM_KIRKWOOD_CPUFREQ
SoCs.
config ARM_MT8173_CPUFREQ
- bool "Mediatek MT8173 CPUFreq support"
- depends on ARCH_MEDIATEK && REGULATOR
+ tristate "Mediatek MT8173 CPUFreq support"
+ depends on ARCH_MEDIATEK && REGULATOR && THERMAL
select PM_OPP
help
This adds the CPUFreq driver support for Mediatek MT8173 SoC.
diff --git a/drivers/cpufreq/mt8173-cpufreq.c b/drivers/cpufreq/mt8173-cpufreq.c
index 49caed293a3b..2131e1a81be9 100644
--- a/drivers/cpufreq/mt8173-cpufreq.c
+++ b/drivers/cpufreq/mt8173-cpufreq.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -524,4 +525,5 @@ static int mt8173_cpufreq_driver_init(void)
return 0;
}
-device_initcall(mt8173_cpufreq_driver_init);
+module_init(mt8173_cpufreq_driver_init);
+MODULE_LICENSE("GPL v2");
--
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/6] extcon: arizona: Additional settings to improve accuracy of HP detect
On 2015년 09월 10일 20:41, Charles Keepax wrote:
> If the TST_CAP_SEL bits aren't set correctly on wm5110/8280 there will
> be a 100k load along side the headphones, which will affect the accurary
> towards the very top of the detection range. This patch sets those bits.
>
> Signed-off-by: Charles Keepax
> ---
> drivers/extcon/extcon-arizona.c | 19 +--
> 1 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index b48fb29..7bfaacd 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -43,6 +43,9 @@
> #define ARIZONA_MICD_CLAMP_MODE_JDL_GP5H 0x9
> #define ARIZONA_MICD_CLAMP_MODE_JDH_GP5H 0xb
>
> +#define ARIZONA_TST_CAP_DEFAULT 0x3
> +#define ARIZONA_TST_CAP_CLAMP 0x1
> +
> #define ARIZONA_HPDET_MAX 1
>
> #define HPDET_DEBOUNCE 500
> @@ -147,6 +150,7 @@ static void arizona_extcon_hp_clamp(struct
> arizona_extcon_info *info,
> {
> struct arizona *arizona = info->arizona;
> unsigned int mask = 0, val = 0;
> + unsigned int cap_sel = 0;
> int ret;
>
> switch (arizona->type) {
> @@ -154,10 +158,21 @@ static void arizona_extcon_hp_clamp(struct
> arizona_extcon_info *info,
> case WM8280:
> mask = ARIZONA_HP1L_SHRTO | ARIZONA_HP1L_FLWR |
> ARIZONA_HP1L_SHRTI;
> - if (clamp)
> + if (clamp) {
> val = ARIZONA_HP1L_SHRTO;
> - else
> + cap_sel = ARIZONA_TST_CAP_CLAMP;
> + } else {
> val = ARIZONA_HP1L_FLWR | ARIZONA_HP1L_SHRTI;
> + cap_sel = ARIZONA_TST_CAP_DEFAULT;
> + }
> +
> + ret = regmap_update_bits(arizona->regmap,
> + ARIZONA_HP_TEST_CTRL_1,
> + ARIZONA_HP1_TST_CAP_SEL_MASK,
> + cap_sel);
> + if (ret != 0)
> + dev_warn(arizona->dev,
> + "Failed to set TST_CAP_SEL: %d\n", ret);
> break;
> default:
> mask = ARIZONA_RMV_SHRT_HP1L;
>
Acked-by: Chanwoo Choi
Thanks,
Chanwoo Choi
--
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 1/4] kvm: factor out core eventfd assign/deassign logic
On 11/09/2015 09:39, Cornelia Huck wrote: > > +static int > > +kvm_deassign_ioeventfd_idx(struct kvm *kvm, enum kvm_bus bus_idx, > > + struct kvm_ioeventfd *args) > > While this file uses newline before function name quite often, putting > it on the same line seems more common - don't know which one the > maintainers prefer. I prefer it this way if it doesn't make the declaration one line longer, which seems to be the case here. Paolo -- 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: cpufreq: mediatek: allow modular build
On 11-09-15, 10:15, Arnd Bergmann wrote:
> The newly merged cpufreq-mt8173 driver breaks the ARM allmodconfig
> build because of a dependency on the cpu-cooling infrastructure that
> may be built as a loadable module:
>
> drivers/built-in.o: In function `mtk_cpufreq_ready':
> binder.c:(.text+0x324c8c): undefined reference to
> `of_cpufreq_cooling_register'
> drivers/built-in.o: In function `mtk_cpufreq_exit':
> binder.c:(.text+0x324ea0): undefined reference to `cpufreq_cooling_unregister'
>
> This works around the issue by allowing this driver to be built
> as a module as well, and adding a dependency on THERMAL that prevents
> it from being built-in when the cpu-cooling driver is a module.
>
> This is not perfect because there is still a case where THERMAL=m
> and CPU_COOLING=n that should allow us to have this driver built-in
> as well, but I decided to follow existing practice in other drivers
> here, and that case seems irrelevant in practice.
>
> Signed-off-by: Arnd Bergmann
> ---
> I have not checked if someone else has already sent a patch for this,
> just ignore mine if the issue has been fixed already.
5269e7067cd6 ("cpufreq: Add ARM_MT8173_CPUFREQ dependency on THERMAL")
in Rafael's tree. Its a bit different, so have a look.
--
viresh
--
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 5/6] sched/fair: Get rid of scaling utilization by capacity_orig
On Thu, Sep 10, 2015 at 12:07:27PM +0200, Peter Zijlstra wrote:
> > > Still don't understand why it's a unit problem. IMHO LOAD/UTIL and
> > > CAPACITY have no unit.
> >
> > To be more accurate, probably, LOAD can be thought of as having unit,
> > but UTIL has no unit.
>
> But I'm thinking that is wrong; it should have one, esp. if we go scale
> the thing. Giving it the same fixed point unit as load simplifies the
> code.
I think we probably are saying the same thing with different terms. Anyway,
let me reiterate what I said and make it a little more formalized.
UTIL has no unit because it is pure ratio, the cpu_running%, which is in the
range of [0, 100%], and we increase the resolution, because we don't want
to lose many (due to integer rounding) by multiplying a number (say 1024), then
the range becomes [0, 1024].
CAPACITY is also a ratio of ACTUAL_PERF/MAX_PERF, from (0, 1]. Even LOAD
is the same, a ratio of NICE_X/NICE_0, from [15/1024=0.015, 88761/1024=86.68],
as it only has relativity meaning (i.e., when comparing to each other).
I said it has unit, it is in the sense that it looks like currency (for
instance,
Yuan), you can use to buy CPU fair share. But it is just how you look at it and
there are certainly many other ways.
So, I still propose to generalize all these with the following patch, in the
belief that this makes it simple and clear, and error-reducing.
--
Subject: [PATCH] sched/fair: Generalize the load/util averages resolution
definition
A integer metric needs certain resolution to allow how much detail we
can look into (not losing detail by integer rounding), which also
determines the range of the metrics.
For instance, to increase the resolution of [0, 1] (two levels), one
can multiply 1024 and get [0, 1024] (1025 levels).
In sched/fair, a few metrics depend on the resolution: load/load_avg,
util_avg, and capacity (frequency adjustment). In order to reduce the
risks of making mistakes relating to resolution/range, we therefore
generalize the resolution by defining a basic resolution constant
number, and then formalize all metrics to depend on the basic
resolution. The basic resolution is 1024 or (1 << 10). Further, one
can recursively apply another basic resolution to increase the final
resolution (e.g., 1048676=1<<20).
Signed-off-by: Yuyang Du
---
include/linux/sched.h | 2 +-
kernel/sched/sched.h | 12 +++-
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 119823d..55a7b93 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -912,7 +912,7 @@ enum cpu_idle_type {
/*
* Increase resolution of cpu_capacity calculations
*/
-#define SCHED_CAPACITY_SHIFT 10
+#define SCHED_CAPACITY_SHIFT SCHED_RESOLUTION_SHIFT
#define SCHED_CAPACITY_SCALE (1L << SCHED_CAPACITY_SHIFT)
/*
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 68cda11..d27cdd8 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -40,6 +40,9 @@ static inline void update_cpu_load_active(struct rq *this_rq)
{ }
*/
#define NS_TO_JIFFIES(TIME)((unsigned long)(TIME) / (NSEC_PER_SEC / HZ))
+# define SCHED_RESOLUTION_SHIFT10
+# define SCHED_RESOLUTION_SCALE(1L << SCHED_RESOLUTION_SHIFT)
+
/*
* Increase resolution of nice-level calculations for 64-bit architectures.
* The extra resolution improves shares distribution and load balancing of
@@ -53,16 +56,15 @@ static inline void update_cpu_load_active(struct rq
*this_rq) { }
* increased costs.
*/
#if 0 /* BITS_PER_LONG > 32 -- currently broken: it increases power usage
under light load */
-# define SCHED_LOAD_RESOLUTION 10
-# define scale_load(w) ((w) << SCHED_LOAD_RESOLUTION)
-# define scale_load_down(w)((w) >> SCHED_LOAD_RESOLUTION)
+# define SCHED_LOAD_SHIFT (SCHED_RESOLUTION_SHIFT +
SCHED_RESOLUTION_SHIFT)
+# define scale_load(w) ((w) << SCHED_RESOLUTION_SHIFT)
+# define scale_load_down(w)((w) >> SCHED_RESOLUTION_SHIFT)
#else
-# define SCHED_LOAD_RESOLUTION 0
+# define SCHED_LOAD_SHIFT (SCHED_RESOLUTION_SHIFT)
# define scale_load(w) (w)
# define scale_load_down(w)(w)
#endif
-#define SCHED_LOAD_SHIFT (10 + SCHED_LOAD_RESOLUTION)
#define SCHED_LOAD_SCALE (1L << SCHED_LOAD_SHIFT)
#define NICE_0_LOADSCHED_LOAD_SCALE
--
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 V2 1/3] arm64: dts: Add reset dts config for Hisilicon Hi6220 SoC
Add reset controller for hi6220 hikey-board.
Signed-off-by: Chen Feng
---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 3f03380..3bbc846 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -167,5 +167,12 @@
clocks = <&ao_ctrl 36>, <&ao_ctrl 36>;
clock-names = "uartclk", "apb_pclk";
};
+
+ reset_ctrl: reset_ctrl@f703 {
+ compatible = "hisilicon,hi6220_reset_ctl";
+ reg = <0x0 0xf703 0x0 0x1000>;
+ #reset-cells = <1>;
+ };
+
};
};
--
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 V2 3/3] reset: hi6220: Reset driver for hisilicon hi6220 SoC
Add reset driver for hi6220-hikey board,this driver supply deassert
of IP. on hi6220 SoC.
Signed-off-by: Chen Feng
---
drivers/reset/Kconfig | 1 +
drivers/reset/Makefile | 1 +
drivers/reset/hisilicon/Kconfig| 5 ++
drivers/reset/hisilicon/Makefile | 1 +
drivers/reset/hisilicon/hi6220_reset.c | 118 +
5 files changed, 126 insertions(+)
create mode 100644 drivers/reset/hisilicon/Kconfig
create mode 100644 drivers/reset/hisilicon/Makefile
create mode 100644 drivers/reset/hisilicon/hi6220_reset.c
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 0615f50..df37212 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -13,3 +13,4 @@ menuconfig RESET_CONTROLLER
If unsure, say no.
source "drivers/reset/sti/Kconfig"
+source "drivers/reset/hisilicon/Kconfig"
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 157d421..331d7b2 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
obj-$(CONFIG_ARCH_STI) += sti/
+obj-$(CONFIG_ARCH_HISI) += hisilicon/
diff --git a/drivers/reset/hisilicon/Kconfig b/drivers/reset/hisilicon/Kconfig
new file mode 100644
index 000..26bf95a
--- /dev/null
+++ b/drivers/reset/hisilicon/Kconfig
@@ -0,0 +1,5 @@
+config COMMON_RESET_HI6220
+ tristate "Hi6220 Reset Driver"
+ depends on (ARCH_HISI && RESET_CONTROLLER)
+ help
+ Build the Hisilicon Hi6220 reset driver.
diff --git a/drivers/reset/hisilicon/Makefile b/drivers/reset/hisilicon/Makefile
new file mode 100644
index 000..c932f86
--- /dev/null
+++ b/drivers/reset/hisilicon/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_COMMON_RESET_HI6220) += hi6220_reset.o
diff --git a/drivers/reset/hisilicon/hi6220_reset.c
b/drivers/reset/hisilicon/hi6220_reset.c
new file mode 100644
index 000..097133d
--- /dev/null
+++ b/drivers/reset/hisilicon/hi6220_reset.c
@@ -0,0 +1,118 @@
+/*
+ * Hisilicon Hi6220 reset controller driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * Author: Feng Chen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ASSET_OFFSET0x300
+#define DEASSET_OFFSET 0x304
+
+struct hi6220_reset_data {
+ spinlock_t reset_lock; /*device spin-lock*/
+ void __iomem*src_base;
+ void __iomem*asset_base;
+ void __iomem*deasset_base;
+ struct reset_controller_dev rc_dev;
+};
+
+static int hi6220_reset_assert(struct reset_controller_dev *rc_dev,
+ unsigned long idx)
+{
+ struct hi6220_reset_data *data = container_of(rc_dev,
+ struct hi6220_reset_data,
+ rc_dev);
+
+ unsigned long flags;
+ int bank = idx >> 8;
+ int offset = idx & 0xff;
+
+ spin_lock_irqsave(&data->reset_lock, flags);
+
+ writel(BIT(offset), data->asset_base + (bank * 0x10));
+
+ spin_unlock_irqrestore(&data->reset_lock, flags);
+
+ return 0;
+}
+
+static int hi6220_reset_deassert(struct reset_controller_dev *rc_dev,
+unsigned long idx)
+{
+ struct hi6220_reset_data *data = container_of(rc_dev,
+ struct hi6220_reset_data,
+ rc_dev);
+
+ unsigned long flags;
+ int bank = idx >> 8;
+ int offset = idx & 0xff;
+
+ spin_lock_irqsave(&data->reset_lock, flags);
+
+ writel(BIT(offset), data->deasset_base + (bank * 0x10));
+
+ spin_unlock_irqrestore(&data->reset_lock, flags);
+
+ return 0;
+}
+
+static struct reset_control_ops hi6220_reset_ops = {
+ .assert = hi6220_reset_assert,
+ .deassert = hi6220_reset_deassert,
+};
+
+static int __init hi6220_reset_init(void)
+{
+ int ret;
+ struct device_node *np;
+ struct hi6220_reset_data *data;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ np = of_find_compatible_node(NULL, NULL, "hisilicon,hi6220_reset_ctl");
+ if (!np) {
+ ret = -ENXIO;
+ goto err_alloc;
+ }
+ spin_lock_init(&data->reset_lock);
+ data->src_base = of_iomap(np, 0);
+ if (!data->src_base) {
+ ret = -ENOMEM;
+ goto err_alloc;
+ }
+
+ data->asset_base = data->src_base + ASSET_OFFSET;
+ data->deasset_base = data->src_base + DEASSET_OFFSET;
+ data->rc_dev.owner = THIS_MODULE;
+ data->rc_dev.nr_resets = SZ_4K;
[PATCH V2 2/3] reset: hisilicon: document hisi-hi6220 reset controllers bindings
Add DT bindings documentation for hi6220 SoC reset controller.
Signed-off-by: Chen Feng
---
.../bindings/reset/hisilicon,hi6220-reset.txt | 97 ++
1 file changed, 97 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
b/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
new file mode 100644
index 000..200dc8e
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
@@ -0,0 +1,97 @@
+Hisilicon System Reset Controller
+==
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+The reset controller node must be a sub-node of the chip controller
+node on SoCs.
+
+Required properties:
+- compatible: may be "hisilicon,hi6220_reset_ctl"
+- reg: should be register base and length as documented in the
+ datasheet
+- #reset-cells: 1, see below
+
+Example:
+
+ reset_ctrl: reset_ctrl@f703 {
+ compatible = "hisilicon,hi6220_reset_ctl";
+ reg = <0x0 0xf703 0x0 0x1000>;
+ #reset-cells = <1>;
+ };
+
+Specifying reset lines connected to IP modules
+==
+example:
+
+uart1: uart1@. {
+ ...
+resets = <&reset_ctrl 0x305>;
+ ...
+};
+
+The following RESET_INDEX values are valid for hi6220 SoC:
+ PERIPH_RSTDIS0_MMC0 = 0x000,
+ PERIPH_RSTDIS0_MMC1 = 0x001,
+ PERIPH_RSTDIS0_MMC2 = 0x002,
+ PERIPH_RSTDIS0_NANDC= 0x003,
+ PERIPH_RSTDIS0_USBOTG_BUS = 0x004,
+ PERIPH_RSTDIS0_POR_PICOPHY = 0x005,
+ PERIPH_RSTDIS0_USBOTG = 0x006,
+ PERIPH_RSTDIS0_USBOTG_32K = 0x007,
+
+ PERIPH_RSTDIS1_HIFI = 0x100,
+ PERIPH_RSTDIS1_DIGACODEC= 0x105,
+
+ PERIPH_RSTEN2_IPF = 0x200,
+ PERIPH_RSTEN2_SOCP = 0x201,
+ PERIPH_RSTEN2_DMAC = 0x202,
+ PERIPH_RSTEN2_SECENG= 0x203,
+ PERIPH_RSTEN2_ABB = 0x204,
+ PERIPH_RSTEN2_HPM0 = 0x205,
+ PERIPH_RSTEN2_HPM1 = 0x206,
+ PERIPH_RSTEN2_HPM2 = 0x207,
+ PERIPH_RSTEN2_HPM3 = 0x208,
+
+ PERIPH_RSTEN3_CSSYS = 0x300,
+ PERIPH_RSTEN3_I2C0 = 0x301,
+ PERIPH_RSTEN3_I2C1 = 0x302,
+ PERIPH_RSTEN3_I2C2 = 0x303,
+ PERIPH_RSTEN3_I2C3 = 0x304,
+ PERIPH_RSTEN3_UART1 = 0x305,
+ PERIPH_RSTEN3_UART2 = 0x306,
+ PERIPH_RSTEN3_UART3 = 0x307,
+ PERIPH_RSTEN3_UART4 = 0x308,
+ PERIPH_RSTEN3_SSP = 0x309,
+ PERIPH_RSTEN3_PWM = 0x30a,
+ PERIPH_RSTEN3_BLPWM = 0x30b,
+ PERIPH_RSTEN3_TSENSOR = 0x30c,
+ PERIPH_RSTEN3_DAPB = 0x312,
+ PERIPH_RSTEN3_HKADC = 0x313,
+ PERIPH_RSTEN3_CODEC_SSI = 0x314,
+ PERIPH_RSTEN3_PMUSSI1 = 0x316,
+
+ PERIPH_RSTEN8_RS0 = 0x400,
+ PERIPH_RSTEN8_RS2 = 0x401,
+ PERIPH_RSTEN8_RS3 = 0x402,
+ PERIPH_RSTEN8_MS0 = 0x403,
+ PERIPH_RSTEN8_MS2 = 0x405,
+ PERIPH_RSTEN8_XG2RAM0 = 0x406,
+ PERIPH_RSTEN8_X2SRAM_TZMA = 0x407,
+ PERIPH_RSTEN8_SRAM = 0x408,
+ PERIPH_RSTEN8_HARQ = 0x40a,
+ PERIPH_RSTEN8_DDRC = 0x40c,
+ PERIPH_RSTEN8_DDRC_APB = 0x40d,
+ PERIPH_RSTEN8_DDRPACK_APB = 0x40e,
+ PERIPH_RSTEN8_DDRT = 0x411,
+
+ PERIPH_RSDIST9_CARM_DAP = 0x500,
+ PERIPH_RSDIST9_CARM_ATB = 0x501,
+ PERIPH_RSDIST9_CARM_LBUS= 0x502,
+ PERIPH_RSDIST9_CARM_POR = 0x503,
+ PERIPH_RSDIST9_CARM_CORE= 0x504,
+ PERIPH_RSDIST9_CARM_DBG = 0x505,
+ PERIPH_RSDIST9_CARM_L2 = 0x506,
+ PERIPH_RSDIST9_CARM_SOCDBG = 0x507,
+ PERIPH_RSDIST9_CARM_ETM = 0x508,
--
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: cpufreq: mediatek: allow modular build
On Friday 11 September 2015 13:47:53 Viresh Kumar wrote:
> On 11-09-15, 10:15, Arnd Bergmann wrote:
> > The newly merged cpufreq-mt8173 driver breaks the ARM allmodconfig
> > build because of a dependency on the cpu-cooling infrastructure that
> > may be built as a loadable module:
> >
> > drivers/built-in.o: In function `mtk_cpufreq_ready':
> > binder.c:(.text+0x324c8c): undefined reference to
> > `of_cpufreq_cooling_register'
> > drivers/built-in.o: In function `mtk_cpufreq_exit':
> > binder.c:(.text+0x324ea0): undefined reference to
> > `cpufreq_cooling_unregister'
> >
> > This works around the issue by allowing this driver to be built
> > as a module as well, and adding a dependency on THERMAL that prevents
> > it from being built-in when the cpu-cooling driver is a module.
> >
> > This is not perfect because there is still a case where THERMAL=m
> > and CPU_COOLING=n that should allow us to have this driver built-in
> > as well, but I decided to follow existing practice in other drivers
> > here, and that case seems irrelevant in practice.
> >
> > Signed-off-by: Arnd Bergmann
> > ---
> > I have not checked if someone else has already sent a patch for this,
> > just ignore mine if the issue has been fixed already.
>
> 5269e7067cd6 ("cpufreq: Add ARM_MT8173_CPUFREQ dependency on THERMAL")
>
> in Rafael's tree. Its a bit different, so have a look.
That fix looks correct to me too, thanks for the quick reply!
In my approach, I decided to allow the driver to be a module, as that
seems nicer for multi_v7_defconfig, but I now see that there are
several other drivers that can only be built-in, so if we decided to
make that the general strategy we should change them all.
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/
平时最多也就联系了三千家，全球还有十几万客户在哪里？
您好: 您还在用ali平台开发外贸客户? 还在使用展会宣传企业和产品? 你out了!!! 当前外贸客户开发难，您是否也在寻找展会，B2B之外好的渠道？ 行业全球十几万客户，平时最多也就联系了三千家，您是否想把剩下的也开发到？ 加QQ2652697913给您演示下主动开发客户的方法，先用先受益，已经有近万家企业领先您使用！！。 广东省商业联合会推荐，主动开发客户第一品牌，近万家企业正在获益。您可以没有使用，但是不能没有了解。 -- 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] x86: Wire up 32-bit direct socket calls
On Mon, Sep 07, 2015 at 02:53:12PM +0200, Arnd Bergmann wrote: > On Wednesday 02 September 2015 13:16:19 H. Peter Anvin wrote: > > On 09/02/2015 02:48 AM, Geert Uytterhoeven wrote: > > > > > > Should all other architectures follow suit? > > > Or should we follow the s390 approach: > > > > > > > It is up to the maintainer(s), largely dependent on how likely you are > > going to want to support this in your libc, but in general, socketcall > > is an abomination which there is no reason not to bypass. > > > > So follow suit unless you have a strong reason not to. > > +1 > > In my y2038 syscall series, I'm adding a new recvmmsg64 call, and > we may decide to add new setsockopt/getsockopt variants as well. > This is probably not the last change to socketcall, and it would > be made much easier if all architectures had separate calls here. > > It seems that there are very few architectures that don't already have > the separate calls: > > $ git grep -l __NR_socketcall arch/*/include/uapi | xargs git grep -L > recvmsg > arch/cris/include/uapi/asm/unistd.h > arch/frv/include/uapi/asm/unistd.h > arch/m32r/include/uapi/asm/unistd.h > arch/m68k/include/uapi/asm/unistd.h > arch/mn10300/include/uapi/asm/unistd.h > arch/s390/include/uapi/asm/unistd.h > > These are of course all examples of architectures that originally followed > the i386 syscall scheme closely rather than trying to leave out obsolete > calls. FWIW, the s390 approach (ignoring the "new" system calls) is only temporarily. I'll enable the seperate calls later when I have time to test everything, especially the glibc stuff. The same is true for the ipc system call. (any reason why the seperate system calls haven't been enabled on x86 now as well?) -- 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: cpufreq: mediatek: allow modular build
On 11-09-15, 10:22, Arnd Bergmann wrote: > In my approach, I decided to allow the driver to be a module, as that > seems nicer for multi_v7_defconfig, but I now see that there are > several other drivers that can only be built-in, so if we decided to > make that the general strategy we should change them all. And we need to do that with a proper module_exit() function, otherwise we are really adding a BUG. Which you just did with your patch :) -- viresh -- 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 3/4] kvm: fix zero length mmio searching
On 11/09/2015 05:17, Jason Wang wrote:
> + int len = r2->len ? r1->len : 0;
> +
> if (r1->addr < r2->addr)
> return -1;
> - if (r1->addr + r1->len > r2->addr + r2->len)
> + if (r1->addr + len > r2->addr + r2->len)
> return 1;
Perhaps better:
gpa_t addr1 = r1->addr;
gpa_t addr2 = r2->addr;
if (addr1 < addr2)
return -1;
/* If r2->len == 0, match the exact address. If r2->len != 0,
* accept any overlapping write. Any order is acceptable for
* overlapping ranges, because kvm_io_bus_get_first_dev ensures
* we process all of them.
*/
if (r2->len) {
addr1 += r1->len;
addr2 += r2->len;
}
if (addr1 > addr2)
return 1;
return 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 0/2] btrfs: fortification for GFP_NOFS allocations
On Wed 09-09-15 18:13:39, Vlastimil Babka wrote:
> On 08/19/2015 08:17 PM, Chris Mason wrote:
> >On Wed, Aug 19, 2015 at 02:17:39PM +0200, mho...@kernel.org wrote:
> >>Hi,
> >>these two patches were sent as a part of a larger RFC which aims at
> >>allowing GFP_NOFS allocations to fail to help sort out memory reclaim
> >>issues bound to the current behavior
> >>(http://marc.info/?l=linux-mm&m=143876830616538&w=2).
> >>
> >>It is clear that move to the GFP_NOFS behavior change is a long term
> >>plan but these patches should be good enough even with that change in
> >>place. It also seems that Chris wasn't opposed and would be willing to
> >>take them http://marc.info/?l=linux-mm&m=143991792427165&w=2 so here we
> >>come. I have rephrased the changeslogs to not refer to the patch which
> >>changes the NOFS behavior.
> >>
> >>Just to clarify. These two patches allowed my particular testcase
> >>(mentioned in the cover referenced above) to survive it doesn't mean
> >>that the failing GFP_NOFS are OK now. I have seen some other places
> >>where GFP_NOFS allocation is followed by BUG_ON(ALLOC_FAILED). I have
> >>not encountered them though.
> >>
> >>Let me know if you would prefer other changes.
> >
> >My plan is to start with these two and take more as required.
>
> I've previously noticed in __set_extent_bit() things like:
>
> if (!prealloc && (mask & __GFP_WAIT)) {
> prealloc = alloc_extent_state(mask);
> BUG_ON(!prealloc);
> }
>
> and later:
>
> prealloc = alloc_extent_state_atomic(prealloc);
> BUG_ON(!prealloc);
Yes. I have noticed also many other places:
$ git grep "BUG_ON.*ENOMEM" -- fs/btrfs/ | wc -l
47
I have talked to David Sterba and he said this is on his todo list.
So this will likely take some more time but it is definitely good to
sort out.
--
Michal Hocko
SUSE Labs
--
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 man-pages v2] capabilities.7, prctl.2: Document ambient capabilities
Hi Andy, Not that this has hit mainline, would you be willing to refresh this man-pages patch? Thanks, Michael On 15 May 2015 at 08:43, Andy Lutomirski wrote: > Signed-off-by: Andy Lutomirski > --- > > There was no v1. I'm calling this v2 to keep it in sync with the kernel > patch versioning. > > man2/prctl.2| 10 ++ > man7/capabilities.7 | 32 ++-- > 2 files changed, 36 insertions(+), 6 deletions(-) > > diff --git a/man2/prctl.2 b/man2/prctl.2 > index b352f6283624..5861e3aefe9a 100644 > --- a/man2/prctl.2 > +++ b/man2/prctl.2 > @@ -949,6 +949,16 @@ had been called. > For further information on Intel MPX, see the kernel source file > .IR Documentation/x86/intel_mpx.txt . > .\" > +.TP > +.BR PR_CAP_AMBIENT " (since Linux 4.2)" > +Reads or changes the ambient capability set. If arg2 is > PR_CAP_AMBIENT_RAISE, > +then the capability specified in arg3 is added to the ambient set. This will > +fail, returning EPERM, if the capability is not already both permitted and > +inheritable or if the SECBIT_NO_CAP_AMBIENT_RAISE securebit is set. If arg2 > +is PR_CAP_AMBIENT_LOWER, then the capability specified in arg3 is removed > +from the ambient set. If arg2 is PR_CAP_AMBIENT_GET, then > +.BR prctl (2) > +will return 1 if the capability in arg3 is in the ambient set and 0 if not. > .SH RETURN VALUE > On success, > .BR PR_GET_DUMPABLE , > diff --git a/man7/capabilities.7 b/man7/capabilities.7 > index d75ec65de05b..dae62f0be3b7 100644 > --- a/man7/capabilities.7 > +++ b/man7/capabilities.7 > @@ -697,13 +697,26 @@ a program whose associated file capabilities grant that > capability). > .IR Inheritable : > This is a set of capabilities preserved across an > .BR execve (2). > -It provides a mechanism for a process to assign capabilities > -to the permitted set of the new program during an > -.BR execve (2). > +Inheritable capabilities remain inheritable when executing any program, > +and inheritable capabilities are added to the permitted set when executing > +a program that has the corresponding bits set in the file inheritable set. > +When executing programs without file capabilities, ambient capabilities > .TP > .IR Effective : > This is the set of capabilities used by the kernel to > perform permission checks for the thread. > +.TP > +.IR Ambient " (since Linux 4.2) :" > +This is a set of capabilities that are preserved across an > +.BR execve (2) > +of a program that does not have file capabilities. The ambient capability > +set obeys the invariant that no capability can ever be ambient if it is > +not both permitted and inheritable. Ambient capabilities are, with some > +exceptions, preserved in the permitted set and added to the effective > +set when > +.BR execve (2) > +is called. The ambient capability set is modified using > +.BR prctl (2). > .PP > A child created via > .BR fork (2) > @@ -785,10 +798,12 @@ the process using the following algorithm: > .in +4n > .nf > > +P'(ambient) = (file has capabilities or is setuid or setgid) ? 0 : P(ambient) > + > P'(permitted) = (P(inheritable) & F(inheritable)) | > -(F(permitted) & cap_bset) > +(F(permitted) & cap_bset) | P'(ambient) > > -P'(effective) = F(effective) ? P'(permitted) : 0 > +P'(effective) = F(effective) ? P'(permitted) : P'(ambient) > > P'(inheritable) = P(inheritable)[i.e., unchanged] > > @@ -1071,6 +1086,10 @@ an effective or real UID of 0 calls > .BR execve (2). > (See the subsection > .IR "Capabilities and execution of programs by root" .) > +.TP > +.B SECBIT_NO_CAP_AMBIENT_RAISE > +Setting this flag disallows > +.BR PR_CAP_AMBIENT_RAISE . > .PP > Each of the above "base" flags has a companion "locked" flag. > Setting any of the "locked" flags is irreversible, > @@ -1079,8 +1098,9 @@ corresponding "base" flag. > The locked flags are: > .BR SECBIT_KEEP_CAPS_LOCKED , > .BR SECBIT_NO_SETUID_FIXUP_LOCKED , > +.BR SECBIT_NOROOT_LOCKED , > and > -.BR SECBIT_NOROOT_LOCKED . > +.BR SECBIT_NO_CAP_AMBIENT_RAISE . > .PP > The > .I securebits > -- > 2.1.0 > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- 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/4] Fast MMIO eventfd fixes
On 11/09/2015 10:15, Michael S. Tsirkin wrote: > I think we should add a capability for fast mmio. > This way, userspace can avoid crashing buggy kernels. I agree. Paolo -- 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 3/4] kvm: fix zero length mmio searching
On Fri, 11 Sep 2015 10:26:41 +0200
Paolo Bonzini wrote:
> On 11/09/2015 05:17, Jason Wang wrote:
> > + int len = r2->len ? r1->len : 0;
> > +
> > if (r1->addr < r2->addr)
> > return -1;
> > - if (r1->addr + r1->len > r2->addr + r2->len)
> > + if (r1->addr + len > r2->addr + r2->len)
> > return 1;
>
> Perhaps better:
>
> gpa_t addr1 = r1->addr;
> gpa_t addr2 = r2->addr;
>
> if (addr1 < addr2)
> return -1;
>
> /* If r2->len == 0, match the exact address. If r2->len != 0,
>* accept any overlapping write. Any order is acceptable for
>* overlapping ranges, because kvm_io_bus_get_first_dev ensures
>* we process all of them.
>*/
> if (r2->len) {
> addr1 += r1->len;
> addr2 += r2->len;
> }
>
> if (addr1 > addr2)
> return 1;
>
> return 0;
>
+1 to documenting what the semantics are :)
--
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: cpufreq: mediatek: allow modular build
On Friday 11 September 2015 13:55:36 Viresh Kumar wrote: > On 11-09-15, 10:22, Arnd Bergmann wrote: > > In my approach, I decided to allow the driver to be a module, as that > > seems nicer for multi_v7_defconfig, but I now see that there are > > several other drivers that can only be built-in, so if we decided to > > make that the general strategy we should change them all. > > And we need to do that with a proper module_exit() function, otherwise > we are really adding a BUG. Which you just did with your patch I don't consider that a bug: a module with just an init function and no exit function can be loaded once and never unloaded, which is not nice for debugging, but is otherwise fully functional. 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: cpufreq: mediatek: allow modular build
On 11-09-15, 10:36, Arnd Bergmann wrote: > I don't consider that a bug: a module with just an init function and > no exit function can be loaded once and never unloaded, which is not > nice for debugging, but is otherwise fully functional. For me, there are two essential things that a module has to support: - hotplug, which is just fine. - hot-unplug, which will pass as well, but without freeing resources.. :) -- viresh -- 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] cpufreq: imx: update the clock switch flow to support imx6ul
On 2015/9/11 16:07, Viresh Kumar wrote:
On 11-09-15, 23:41, Bai Ping wrote:
+ if (of_machine_is_compatible("fsl,imx6ul")) {
+ pll2_bus_clk = clk_get(cpu_dev, "pll2_bus");
+ secondary_sel_clk = clk_get(cpu_dev, "secondary_sel");
+ if (IS_ERR(pll2_bus_clk) || IS_ERR(secondary_sel_clk)) {
+ dev_err(cpu_dev, "failed to get clocks specific to
imx6ul\n");
+ ret = -ENOENT;
+ goto put_clk;
+ }
+ }
+
arm_reg = regulator_get(cpu_dev, "arm");
pu_reg = regulator_get_optional(cpu_dev, "pu");
soc_reg = regulator_get(cpu_dev, "soc");
@@ -331,6 +365,10 @@ put_clk:
clk_put(step_clk);
if (!IS_ERR(pll2_pfd2_396m_clk))
clk_put(pll2_pfd2_396m_clk);
+ if (!IS_ERR(pll2_bus_clk))
+ clk_put(pll2_bus_clk);
+ if (!IS_ERR(secondary_sel_clk))
+ clk_put(secondary_sel_clk);
of_node_put(np);
return ret;
}
As part of good coding practices, you should free resources in the
reverse order to which they were allocated. The clocks don't follow
that, but its not a problem with just your patch. That's how it is
present today. Maybe you can write another patch to fix that.
thanks for your suggestion, I will pay more attention to it in future
coding.
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig
On Thu, Sep 10, 2015 at 01:10:19PM +0100, Morten Rasmussen wrote: > > > so it appear to be intended to be using low resolution like load_avg > > > (weight is scaled down before it is passed into __update_load_avg()), > > > but util_avg is shifted up to high resolution. It should be: > > > > > > sa->util_avg = (sa->util_sum << (SCHED_LOAD_SHIFT - > > > SCHED_LOAD_SHIFT)) / LOAD_AVG_MAX; > > > > you probably mean (SCHED_LOAD_SHIFT - SCHED_LOAD_RESOLUTION) > > Yes. Thanks for providing the right expression. There seems to be enough > confusion in this thread already :) And yes, it is my bad in the first place, sorry, I did not think it though :) > > The goal of this patchset is to be able to scale util_avg in the range > > of cpu capacity so why don't we directly initialize it with > > sa->util_avg = SCHED_CAPACITY_SCALE; Yes, we should, and specifically, it is bacause we can combine the resolution thing for util% * capacity%, so we only need to use the resolution once. > > and then use > > > > sa->util_avg = (sa->util_sum << SCHED_CAPACITY_SHIFT) / LOAD_AVG_MAX; > > > > so we don't have to take care of high and low load resolution > > That works for me, except that the left-shift has gone be PeterZ's > optimization patch posted earlier in this thread. It is changing > util_sum to scaled by capacity instead of being the pure geometric > series which requires the left shift at the end when we divide by > LOAD_AVG_MAX. So it should be equivalent to what you are proposing if we > change the initialization to your proposal too. I previously initialized the util_sum as: sa->util_sum = LOAD_AVG_MAX; it is because wihout capacity adjustment, this can save some multiplications in __update_load_avg(), but actually if we do capacity adjustment, we must multiply anyway, so it is better we initialize it as: sa->util_sum = sa->util_avg * LOAD_AVG_MAX; Anyway, with the patch I posted in the other email in this thread, we can fix all this very clearly, I hope so. I did not post a fix patch, it is because the solutions are already there, it is just how we make it look better, and you can provide it in your new version. Thanks, Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 3/3] reset: hi6220: Reset driver for hisilicon hi6220 SoC
On Friday 11 September 2015 16:18:38 Chen Feng wrote:
> +static int __init hi6220_reset_init(void)
> +{
> + int ret;
> + struct device_node *np;
> + struct hi6220_reset_data *data;
> +
> + data = kzalloc(sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + np = of_find_compatible_node(NULL, NULL, "hisilicon,hi6220_reset_ctl");
> + if (!np) {
> + ret = -ENXIO;
> + goto err_alloc;
> + }
Why is this not a platform driver?
> + if (IS_ENABLED(CONFIG_RESET_CONTROLLER))
> + reset_controller_register(&data->rc_dev);
> +
> + return 0;
The Kconfig symbol already depends on RESET_CONTROLLER, so
the IS_ENABLED() check looks redundant.
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 V1] x86, mce: CPU synchronization for broadcast MCE's is surprised by offline CPUs
On Thu, Sep 10, 2015 at 08:26:38PM -0400, Ashok Raj wrote:
> +#define OFFLINE_CPU_LOG_LEN 16
> +
> +struct offline_cpu_mce {
> + unsigned short head;
> + unsigned short tail;
> + struct mce mce_log[OFFLINE_CPU_LOG_LEN];
> +};
> +
> +static struct offline_cpu_mce offline_mce;
> +static unsigned int offline_mce_overflow = 0;
> +
> +/*
> + * Add mce's discovered in offline cpu which will be logged by the
> + * MCE rendezvous master. There is no lock required, since MCE's are
> + * processed one cpu at a time, sequenced by the rendezvous master CPU
> + * Safe to be called only from MCE handler.
> + */
> +static int offline_mce_add(struct mce *m)
> +{
> + unsigned next;
> +
> + next = (offline_mce.tail + 1) % OFFLINE_CPU_LOG_LEN;
> + if (next == offline_mce.head) {
> + offline_mce_overflow++;
> + return -1;
> + }
> +
> + offline_mce.mce_log[offline_mce.tail] = *m;
> + offline_mce.tail = next;
> + return 0;
> +}
> +
> +static int offline_mce_get(struct mce *m)
> +{
> + int ret = 0;
> +
> + if (offline_mce.head == offline_mce.tail)
> + goto out;
> +
> + *m = offline_mce.mce_log[offline_mce.head];
> + offline_mce.head = (offline_mce.head + 1) % OFFLINE_CPU_LOG_LEN;
> +
> + ret = 1;
> +out:
> + return ret;
> +}
One more buffer for MCEs? Why?
We did add the mce_gen_pool thing exactly for logging stuff in atomic
context. From looking at the code, we probably could get rid of that
"struct mce_log mcelog" thing too and use only the gen_pool for logging
MCEs.
We can then get rid of that MCE_LOG_LEN arbitrary 32 records and use
a nice 2-paged buffer which can be enlarged transparently later, if
needed.
Hmmm?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
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 01/23] userfaultfd: linux/Documentation/vm/userfaultfd.txt
On 05/14/2015 07:30 PM, Andrea Arcangeli wrote: > Add documentation. Hi Andrea, I do not recall... Did you write a man page also for this new system call? Thanks, Michael > Signed-off-by: Andrea Arcangeli > --- > Documentation/vm/userfaultfd.txt | 140 > +++ > 1 file changed, 140 insertions(+) > create mode 100644 Documentation/vm/userfaultfd.txt > > diff --git a/Documentation/vm/userfaultfd.txt > b/Documentation/vm/userfaultfd.txt > new file mode 100644 > index 000..c2f5145 > --- /dev/null > +++ b/Documentation/vm/userfaultfd.txt > @@ -0,0 +1,140 @@ > += Userfaultfd = > + > +== Objective == > + > +Userfaults allow the implementation of on-demand paging from userland > +and more generally they allow userland to take control various memory > +page faults, something otherwise only the kernel code could do. > + > +For example userfaults allows a proper and more optimal implementation > +of the PROT_NONE+SIGSEGV trick. > + > +== Design == > + > +Userfaults are delivered and resolved through the userfaultfd syscall. > + > +The userfaultfd (aside from registering and unregistering virtual > +memory ranges) provides two primary functionalities: > + > +1) read/POLLIN protocol to notify a userland thread of the faults > + happening > + > +2) various UFFDIO_* ioctls that can manage the virtual memory regions > + registered in the userfaultfd that allows userland to efficiently > + resolve the userfaults it receives via 1) or to manage the virtual > + memory in the background > + > +The real advantage of userfaults if compared to regular virtual memory > +management of mremap/mprotect is that the userfaults in all their > +operations never involve heavyweight structures like vmas (in fact the > +userfaultfd runtime load never takes the mmap_sem for writing). > + > +Vmas are not suitable for page- (or hugepage) granular fault tracking > +when dealing with virtual address spaces that could span > +Terabytes. Too many vmas would be needed for that. > + > +The userfaultfd once opened by invoking the syscall, can also be > +passed using unix domain sockets to a manager process, so the same > +manager process could handle the userfaults of a multitude of > +different processes without them being aware about what is going on > +(well of course unless they later try to use the userfaultfd > +themselves on the same region the manager is already tracking, which > +is a corner case that would currently return -EBUSY). > + > +== API == > + > +When first opened the userfaultfd must be enabled invoking the > +UFFDIO_API ioctl specifying a uffdio_api.api value set to UFFD_API (or > +a later API version) which will specify the read/POLLIN protocol > +userland intends to speak on the UFFD. The UFFDIO_API ioctl if > +successful (i.e. if the requested uffdio_api.api is spoken also by the > +running kernel), will return into uffdio_api.features and > +uffdio_api.ioctls two 64bit bitmasks of respectively the activated > +feature of the read(2) protocol and the generic ioctl available. > + > +Once the userfaultfd has been enabled the UFFDIO_REGISTER ioctl should > +be invoked (if present in the returned uffdio_api.ioctls bitmask) to > +register a memory range in the userfaultfd by setting the > +uffdio_register structure accordingly. The uffdio_register.mode > +bitmask will specify to the kernel which kind of faults to track for > +the range (UFFDIO_REGISTER_MODE_MISSING would track missing > +pages). The UFFDIO_REGISTER ioctl will return the > +uffdio_register.ioctls bitmask of ioctls that are suitable to resolve > +userfaults on the range registered. Not all ioctls will necessarily be > +supported for all memory types depending on the underlying virtual > +memory backend (anonymous memory vs tmpfs vs real filebacked > +mappings). > + > +Userland can use the uffdio_register.ioctls to manage the virtual > +address space in the background (to add or potentially also remove > +memory from the userfaultfd registered range). This means a userfault > +could be triggering just before userland maps in the background the > +user-faulted page. > + > +The primary ioctl to resolve userfaults is UFFDIO_COPY. That > +atomically copies a page into the userfault registered range and wakes > +up the blocked userfaults (unless uffdio_copy.mode & > +UFFDIO_COPY_MODE_DONTWAKE is set). Other ioctl works similarly to > +UFFDIO_COPY. > + > +== QEMU/KVM == > + > +QEMU/KVM is using the userfaultfd syscall to implement postcopy live > +migration. Postcopy live migration is one form of memory > +externalization consisting of a virtual machine running with part or > +all of its memory residing on a different node in the cloud. The > +userfaultfd abstraction is generic enough that not a single line of > +KVM kernel code had to be modified in order to add postcopy live > +migration to QEMU. > + > +Guest async page faults, FOLL_NOWAIT and all other GUP features work > +just fine in combination with userfaults
Re: [PATCH] x86: Wire up 32-bit direct socket calls
On Friday 11 September 2015 10:24:29 Heiko Carstens wrote: > > FWIW, the s390 approach (ignoring the "new" system calls) is only temporarily. > I'll enable the seperate calls later when I have time to test everything, > especially the glibc stuff. Ok, thanks for clarifying. > The same is true for the ipc system call. (any reason why the seperate system > calls haven't been enabled on x86 now as well?) Agreed, we should split that out on all architectures as well. Almost the same set of architectures that have sys_socketcall also have sys_ipc, and the reasons for changing are identical. I don't think we have any other system calls that are handled like this on some architectures but not on others. There are a couple of system calls (e.g. futex) that are also multiplexers, but at least they do it consistently. 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 v2 1/5] ACPI: add in a bad_madt_entry() function to eventually replace the macro
On 10/09/15 21:43, Al Stone wrote: On 09/10/2015 10:20 AM, Sudeep Holla wrote: [...] From the code inspection, I can see we have 3 users of acpi_parse_entries not just MADT but also PCC and NUMA/SRAT Something like this solves this issue: - if (bad_madt_entry(table_header, entry)) + if (!strncmp(id, ACPI_SIG_MADT, 4) && + bad_madt_entry(table_header, entry) Or am I still missing something ? Nope, I missed it. Your fix above will solve the problem; I misunderstood how acpi_parse_entries() was being used -- somehow I had it in my head that only MADT was in use, and just not seeing that it's being used for several other subtable traversals also. Sorry about that, Sudeep. My mistake. No worries. I'll add this fix for a v4, but I'll wait for a few days to see if I get any additional comments -- I haven't heard from any x86, ia64 or ACPI maintainers Makes sense. yet. OTOH, it's nice to know we've already found and fixed two sets of arm64 ACPI tables that are in error by using these patches, even with the flaws :). Very much true indeed :) Regards, Sudeep -- 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 1/5] mfd: arizona: Add registers for ADC microphone detection
On Fri, 11 Sep 2015, Chanwoo Choi wrote: > I make the temporary branch[1] and then apply patch1-patch4 without patch5 > because of patch5 may need the ack message by DT maintainer. If Lee want to > make the immutable branch and send the pull request, I'll make the immutable > branch based on Linux-4.3-rcX and send it to MFD maintainer (Lee Jones). > [1] branch name : extcon-next-v4.4-for-arizona > - > git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-next-v4.4-for-arizona > > I need the your opinion. I'm not sure we need two immutable branches. I'm happy to create one. All I need are Acks for the patches which touch extcon. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] mmc: sdhci-of-arasan: add phy support for sdhci-of-arasan
This patch adds Generic PHY access for sdhci-of-arasan. Driver
can get PHY handler from dt-binding, and power-on/init the PHY.
Also we add pm ops for PHY here if CONFIG_PM_SLEEP is enabled.
Signed-off-by: Shawn Lin
---
drivers/mmc/host/sdhci-of-arasan.c | 90 ++
1 file changed, 90 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index 621c3f4..fdd71c7 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include "sdhci-pltfm.h"
#define SDHCI_ARASAN_CLK_CTRL_OFFSET 0x2c
@@ -35,6 +36,7 @@
*/
struct sdhci_arasan_data {
struct clk *clk_ahb;
+ struct phy *phy;
};
static unsigned int sdhci_arasan_get_timeout_clock(struct sdhci_host *host)
@@ -67,6 +69,62 @@ static struct sdhci_pltfm_data sdhci_arasan_pdata = {
#ifdef CONFIG_PM_SLEEP
/**
+ * sdhci_arasan_suspend_phy - Suspend phy method for the driver
+ * @phy:Handler of phy structure
+ * Returns 0 on success and error value on error
+ *
+ * Put the phy in a deactive state.
+ */
+static int sdhci_arasan_suspend_phy(struct phy *phy)
+{
+ int ret;
+
+ ret = phy_exit(phy);
+ if (ret < 0)
+ goto err_phy_exit;
+
+ ret = phy_power_off(phy);
+ if (ret < 0)
+ goto err_phy_pwr_off;
+
+ return 0;
+
+err_phy_pwr_off:
+ phy_power_on(phy);
+err_phy_exit:
+ phy_init(phy);
+ return ret;
+}
+
+/**
+ * sdhci_arasan_resume_phy - Resume phy method for the driver
+ * @phy:Handler of phy structure
+ * Returns 0 on success and error value on error
+ *
+ * Put the phy in a active state.
+ */
+static int sdhci_arasan_resume_phy(struct phy *phy)
+{
+ int ret;
+
+ ret = phy_power_on(phy);
+ if (ret < 0)
+ goto err_phy_pwr_on;
+
+ ret = phy_init(phy);
+ if (ret < 0)
+ goto err_phy_init;
+
+ return 0;
+
+err_phy_init:
+ phy_exit(phy);
+err_phy_pwr_on:
+ phy_power_off(phy);
+ return ret;
+}
+
+/**
* sdhci_arasan_suspend - Suspend method for the driver
* @dev: Address of the device structure
* Returns 0 on success and error value on error
@@ -88,6 +146,12 @@ static int sdhci_arasan_suspend(struct device *dev)
clk_disable(pltfm_host->clk);
clk_disable(sdhci_arasan->clk_ahb);
+ if (sdhci_arasan->phy) {
+ ret = sdhci_arasan_suspend_phy(sdhci_arasan->phy);
+ if (ret < 0)
+ return ret;
+ }
+
return 0;
}
@@ -119,6 +183,12 @@ static int sdhci_arasan_resume(struct device *dev)
return ret;
}
+ if (sdhci_arasan->phy) {
+ ret = sdhci_arasan_resume_phy(sdhci_arasan->phy);
+ if (ret < 0)
+ return ret;
+ }
+
return sdhci_resume_host(host);
}
#endif /* ! CONFIG_PM_SLEEP */
@@ -163,6 +233,26 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
goto clk_dis_ahb;
}
+ sdhci_arasan->phy = devm_phy_get(&pdev->dev, "phy_arasan");
+ if (!IS_ERR(sdhci_arasan->phy)) {
+ ret = phy_power_on(sdhci_arasan->phy);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "phy_power_on err.\n");
+ phy_power_off(sdhci_arasan->phy);
+ goto clk_dis_ahb;
+ }
+
+ ret = phy_init(sdhci_arasan->phy);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "phy_init err.\n");
+ phy_exit(sdhci_arasan->phy);
+ phy_power_off(sdhci_arasan->phy);
+ goto clk_dis_ahb;
+ }
+ } else {
+ sdhci_arasan->phy = NULL;
+ }
+
host = sdhci_pltfm_init(pdev, &sdhci_arasan_pdata, 0);
if (IS_ERR(host)) {
ret = PTR_ERR(host);
--
2.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Documentation: bindings: add description of phy for sdhci-of-arasan
This patch adds phys and phy-names for sdhci-of-arasan as optional
properties, and details the example as well.
Signed-off-by: Shawn Lin
---
Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
index da541c3..0264d5f 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -1,11 +1,12 @@
Device Tree Bindings for the Arasan SDHCI Controller
- The bindings follow the mmc[1], clock[2] and interrupt[3] bindings. Only
- deviations are documented here.
+ The bindings follow the mmc[1], clock[2], interrupt[3] and phy[4] bindings.
+ Only deviations are documented here.
[1] Documentation/devicetree/bindings/mmc/mmc.txt
[2] Documentation/devicetree/bindings/clock/clock-bindings.txt
[3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+ [4] Documentation/devicetree/bindings/phy/phy-bindings.txt
Required Properties:
- compatible: Compatibility string. Must be 'arasan,sdhci-8.9a' or
@@ -16,6 +17,9 @@ Required Properties:
- interrupts: Interrupt specifier
- interrupt-parent: Phandle for the interrupt controller that services
interrupts for this device.
+Optional Properties:
+ - phys: From PHY bindings: Phandle for the Generic PHY for arasan.
+ - phy-names: MUST be "phy_arasan".
Example:
sdhci@e010 {
@@ -25,4 +29,6 @@ Example:
clocks = <&clkc 21>, <&clkc 32>;
interrupt-parent = <&gic>;
interrupts = <0 24 4>;
+ phys = <&emmc_phy>;
+ phy-names = "phy_arasan";
} ;
--
2.3.7
--
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/
Skrzynka Pocztowa Zostala Tymczasowo Zawieszona!!!
Konto e-mail uzytkownika Drogi, Niedawno wykryto nietypowe dzialania z konta e-mail, wiec skrzynka pocztowa zostala tymczasowo zawieszona przez administratora systemu, nalezy odzyskac swoje konto, klikajac na ponizszy link lub skopiuj do przegladarki: http://systemadminpocztasecurepage.ezweb123.com/ W zwiazku z tym, mozna otrzymac te wiadomosc w folderze spamu, prosimy przejsc do skrzynki odbiorczej i kliknij w link. Przepraszamy za niedogodnosci. Systemu Administrator @ 2015. All Rights Reserved. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- 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] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.
On Wed, Sep 9, 2015 at 12:36 AM, Steven Rostedt wrote: > On Tue, 08 Sep 2015 11:19:14 -0500 > ebied...@xmission.com (Eric W. Biederman) wrote: > > >> This patch does not implement the old behavior. >> >> The old code does use '\0' as a buffer terminator, and because it does >> not check things closely I can see how it could accept a '\0' from >> userspace and treat that as an early buffer terminator. >> >> The patch treats '\0' as a number separator and allows things that have >> never been allowed before and quite frankly is very scary as it just >> invites bugs. >> >> So I do not think we should merge the given patch. It is just wrong. >> One that simply truncates the input buffer at the first '\0' character I >> think we can consider, although I am not a fan. > > I agree, and was thinking this patch did that, but I didn't look close > enough (why I never gave a Reviewed-by to it either). > > >> >> Steve as far as what I think would break. I don't think the current >> behavior should have broken anything and apparently it did. I don't see >> what a change that simply truncates the buffer at the first embedded >> '\0' would break, but I don't know how to test that there isn't anything >> that it will. We are way past the point of reasonable expectations >> being able to guide us. 4 years should have been more than enough soak >> time to have been able to say that the change was good, but apparently >> it was not. > > Well, to be fair, a lot of people (distros, etc) do not use the most > recent kernels. 4 years may be the first time a tool touches a kernel. > >> >> My gut feel says that if we are going to change this, at this late date, >> we find the one specific proc file that matters and change it just for >> that one proc file, and in that change we treat '\0' as a terminator not >> as a separator. I never did see in the conversation which proc file it >> is that actually matters. The principle is that the more precise and >> the more localized such a change is the less chance it has of causing a >> regression of something else, and the greater the chance we can look at >> a specific issue. > > Sounds like a reasonable compromise. Sean, can you make a patch that > only affects the one proc file (comment it well in the code), and have > it accept nothing past the '\0'. Even if someone passed in "1 \0 2", it > would only see "1 " The current code uses uniform handler (e.g. "proc_dointvec") for all same type proc file. So all integer type proc file are affected. In fact, The behavior of all integer type proc file should be changed. > > -- Steve -- 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] debugfs: don't access 4 bytes for a boolean
Long back 'bool' type used to be a typecast to 'int', but that changed
in v2.6.19. And that is a typecast to _Bool now, which (mostly) takes
just a byte. Anyway, the bool type in kernel is used to store true/false
or 1/0 only. So, accessing a single byte should be enough.
The problem with current code is that it reads/writes 4 bytes for a
boolean, which will read/update 3 excess bytes following the boolean
variable. And that can lead to hard to fix bugs. It was a nightmare to
crack this one.
The debugfs code had this bug since the first time it got introduced,
but was never got caught, strange. Maybe the bool variables (monitored
by debugfs) were followed by an 'int' or something bigger and the pad
bytes made sure, we never see this issue.
But the OPP (Operating performance points) library have three booleans
allocated to contiguous bytes and this bug got hit quite soon (The
debugfs support for OPP is yet to be merged).
Fix this by changing type of 'val' pointer to u8 type, so that we only
access a single byte.
Signed-off-by: Viresh Kumar
---
Greg,
I wasn't sure about what to add the stable tag. This bug is around for a
really long time now.
And this also gets me worrying if any other part of the kernel are
treating booleans in a similar way :)
Also, there is another problem I see, which probably should be fixed as
well. But I wanted to hear from you before trying to patch the kernel
for this.
debugfs_create_bool() declares the pointer to be of type u32 *.
Shouldn't that be changed to u8 *? There are many users which are
typecasting the variables to make debugfs API happy :)
fs/debugfs/file.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 284f9aa0028b..c123185a296a 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -439,7 +439,7 @@ static ssize_t read_file_bool(struct file *file, char
__user *user_buf,
size_t count, loff_t *ppos)
{
char buf[3];
- u32 *val = file->private_data;
+ u8 *val = file->private_data;
if (*val)
buf[0] = 'Y';
@@ -456,7 +456,7 @@ static ssize_t write_file_bool(struct file *file, const
char __user *user_buf,
char buf[32];
size_t buf_size;
bool bv;
- u32 *val = file->private_data;
+ u8 *val = file->private_data;
buf_size = min(count, (sizeof(buf)-1));
if (copy_from_user(buf, user_buf, buf_size))
--
2.4.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 2/2] [media] media-device: split media initialization and registration
Em Fri, 11 Sep 2015 09:31:36 +0200 Javier Martinez Canillas escreveu: > Hello Sakari, > > On 09/11/2015 07:51 AM, Sakari Ailus wrote: > > Hi Javier, > > > > Javier Martinez Canillas wrote: > >> Hello Sakari, > >> > >> On 09/10/2015 07:14 PM, Sakari Ailus wrote: > >>> Hi Javier, > >>> > >>> Thanks for the set! A few comments below. > >>> > >> > >> Thanks to you for your feedback. > >> > >>> Javier Martinez Canillas wrote: > The media device node is registered and so made visible to user-space > before entities are registered and links created which means that the > media graph obtained by user-space could be only partially enumerated > if that happens too early before all the graph has been created. > > To avoid this race condition, split the media init and registration > in separate functions and only register the media device node when > all the pending subdevices have been registered, either explicitly > by the driver or asynchronously using v4l2_async_register_subdev(). > > Also, add a media_entity_cleanup() function that will destroy the > graph_mutex that is initialized in media_entity_init(). > > Suggested-by: Sakari Ailus > Signed-off-by: Javier Martinez Canillas > > --- > > drivers/media/common/siano/smsdvb-main.c | 1 + > drivers/media/media-device.c | 38 > +++ > drivers/media/platform/exynos4-is/media-dev.c | 12 ++--- > drivers/media/platform/omap3isp/isp.c | 11 +--- > drivers/media/platform/s3c-camif/camif-core.c | 13 ++--- > drivers/media/platform/vsp1/vsp1_drv.c| 19 ++ > drivers/media/platform/xilinx/xilinx-vipp.c | 11 +--- > drivers/media/usb/au0828/au0828-core.c| 26 +- > drivers/media/usb/cx231xx/cx231xx-cards.c | 22 +++- > drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 11 +--- > drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 13 ++--- > drivers/media/usb/siano/smsusb.c | 14 -- > drivers/media/usb/uvc/uvc_driver.c| 9 +-- > include/media/media-device.h | 2 ++ > 14 files changed, 156 insertions(+), 46 deletions(-) > > diff --git a/drivers/media/common/siano/smsdvb-main.c > b/drivers/media/common/siano/smsdvb-main.c > index ab345490a43a..8a1ea2192439 100644 > --- a/drivers/media/common/siano/smsdvb-main.c > +++ b/drivers/media/common/siano/smsdvb-main.c > @@ -617,6 +617,7 @@ static void smsdvb_media_device_unregister(struct > smsdvb_client_t *client) > if (!coredev->media_dev) > return; > media_device_unregister(coredev->media_dev); > +media_device_cleanup(coredev->media_dev); > kfree(coredev->media_dev); > coredev->media_dev = NULL; > #endif > diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c > index 745defb34b33..a8beb0b445a6 100644 > --- a/drivers/media/media-device.c > +++ b/drivers/media/media-device.c > @@ -526,7 +526,7 @@ static void media_device_release(struct > media_devnode *mdev) > } > > /** > - * media_device_register - register a media device > + * media_device_init() - initialize a media device > * @mdev:The media device > * > * The caller is responsible for initializing the media device before > @@ -534,12 +534,11 @@ static void media_device_release(struct > media_devnode *mdev) > * > * - dev must point to the parent device > * - model must be filled with the device model name > + * > + * returns zero on success or a negative error code. > */ > -int __must_check __media_device_register(struct media_device *mdev, > - struct module *owner) > +int __must_check media_device_init(struct media_device *mdev) > >>> > >>> I think I suggested making media_device_init() return void as the only > >>> remaining source of errors would be driver bugs. > >>> > >> > >> Yes you did and I think I explained why I preferred to leave it as > >> is and I thought we agreed :) > > > > I thought we agreed, too. But my understanding was that the agreement was > > different. ;-) > > > > Fair enough :) > > >> > >> Currently media_device_register() is failing gracefully if a buggy > >> driver is not setting mdev->dev. So changing media_device_init() to > >> return void instead, would be a semantic change and if drivers are > >> not checking that anymore, can lead to NULL pointer dereference bugs. > > > > Do we have such drivers? Would they ever have worked in the first place, as > > media device registration would have failed? Actually we do. The media controller is an optional feature at the DV
Re: [PATCH V4 1/4] kvm: factor out core eventfd assign/deassign logic
On 09/11/2015 03:39 PM, Cornelia Huck wrote:
> On Fri, 11 Sep 2015 11:17:34 +0800
> Jason Wang wrote:
>
>> This patch factors out core eventfd assign/deassign logic and leave
>> the argument checking and bus index selection to callers.
>>
>> Cc: Gleb Natapov
>> Cc: Paolo Bonzini
>> Signed-off-by: Jason Wang
>> ---
>> virt/kvm/eventfd.c | 83
>> --
>> 1 file changed, 49 insertions(+), 34 deletions(-)
>>
>> diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
>> index 9ff4193..163258d 100644
>> --- a/virt/kvm/eventfd.c
>> +++ b/virt/kvm/eventfd.c
>> @@ -771,40 +771,14 @@ static enum kvm_bus ioeventfd_bus_from_flags(__u32
>> flags)
>> return KVM_MMIO_BUS;
>> }
>>
>> -static int
>> -kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
>> +static int kvm_assign_ioeventfd_idx(struct kvm *kvm,
>> +enum kvm_bus bus_idx,
>> +struct kvm_ioeventfd *args)
>> {
>> -enum kvm_bus bus_idx;
>> -struct _ioeventfd*p;
>> -struct eventfd_ctx *eventfd;
>> -int ret;
>> -
>> -bus_idx = ioeventfd_bus_from_flags(args->flags);
>> -/* must be natural-word sized, or 0 to ignore length */
>> -switch (args->len) {
>> -case 0:
>> -case 1:
>> -case 2:
>> -case 4:
>> -case 8:
>> -break;
>> -default:
>> -return -EINVAL;
>> -}
>>
>> -/* check for range overflow */
>> -if (args->addr + args->len < args->addr)
>> -return -EINVAL;
>> -
>> -/* check for extra flags that we don't understand */
>> -if (args->flags & ~KVM_IOEVENTFD_VALID_FLAG_MASK)
>> -return -EINVAL;
>> -
>> -/* ioeventfd with no length can't be combined with DATAMATCH */
>> -if (!args->len &&
>> -args->flags & (KVM_IOEVENTFD_FLAG_PIO |
>> - KVM_IOEVENTFD_FLAG_DATAMATCH))
>> -return -EINVAL;
>> +struct eventfd_ctx *eventfd;
>> +struct _ioeventfd *p;
>> +int ret;
>>
>> eventfd = eventfd_ctx_fdget(args->fd);
>> if (IS_ERR(eventfd))
>> @@ -873,14 +847,48 @@ fail:
>> }
>>
>> static int
>> -kvm_deassign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
>> +kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
> You'll move this function to below the deassign function in patch 2.
> Maybe do it already here?
>
Yes, this can reduce the changes for patch2.
--
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/
[3.16.y-ckt stable] Linux 3.16.7-ckt17
I am announcing the release of the Linux 3.16.7-ckt17 kernel. The updated 3.16.y-ckt tree can be found at: git://kernel.ubuntu.com/ubuntu/linux.git linux-3.16.y and can be browsed at: http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.16.y The diff from v3.16.7-ckt16 is posted as a follow-up to this email. The 3.16.y-ckt extended stable tree is maintained by the Canonical Kernel Team. For more info, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable -Luis -- Documentation/ABI/testing/ima_policy | 6 +- Makefile | 2 +- arch/arm/boot/dts/imx35.dtsi | 8 +- arch/arm/mach-omap2/omap_hwmod.c | 24 ++- arch/arm64/kernel/efi.c| 4 +- arch/arm64/kernel/signal32.c | 5 +- arch/arm64/kvm/inject_fault.c | 12 +- arch/avr32/mach-at32ap/clock.c | 20 +- arch/mips/include/asm/pgtable.h| 31 +++ arch/mips/include/asm/stackframe.h | 25 +++ arch/mips/kernel/mips-mt-fpaff.c | 5 +- arch/mips/kernel/scall64-64.S | 2 +- arch/mips/kernel/scall64-n32.S | 2 +- arch/mips/kernel/signal32.c| 2 - arch/mips/kernel/traps.c | 13 ++ arch/mips/mti-malta/malta-time.c | 15 +- arch/powerpc/kernel/signal_32.c| 2 - arch/s390/hypfs/inode.c| 12 +- arch/sparc/include/asm/visasm.h| 16 +- arch/sparc/lib/NG4memcpy.S | 5 +- arch/sparc/lib/VISsave.S | 67 +-- arch/sparc/lib/ksyms.c | 4 - arch/x86/boot/compressed/eboot.c | 4 + arch/x86/include/asm/desc.h| 15 -- arch/x86/include/asm/mmu.h | 3 +- arch/x86/include/asm/mmu_context.h | 48 - arch/x86/kernel/cpu/common.c | 4 +- arch/x86/kernel/cpu/perf_event.c | 13 +- arch/x86/kernel/ldt.c | 262 ++--- arch/x86/kernel/process_64.c | 4 +- arch/x86/kernel/step.c | 8 +- arch/x86/kvm/x86.c | 2 +- arch/x86/math-emu/fpu_entry.c | 3 +- arch/x86/math-emu/fpu_system.h | 21 +- arch/x86/math-emu/get_address.c| 3 +- arch/x86/power/cpu.c | 3 +- arch/x86/xen/enlighten.c | 40 drivers/ata/libata-core.c | 1 + drivers/base/firmware_class.c | 16 +- drivers/base/regmap/regcache-rbtree.c | 19 +- drivers/block/rbd.c| 22 ++- drivers/block/xen-blkback/blkback.c| 4 +- drivers/block/xen-blkfront.c | 6 +- drivers/crypto/caam/caamhash.c | 7 +- drivers/crypto/ixp4xx_crypto.c | 1 - drivers/edac/ppc4xx_edac.c | 2 +- drivers/firmware/efi/efi.c | 6 +- drivers/gpu/drm/i915/i915_drv.h| 17 +- drivers/gpu/drm/radeon/radeon_combios.c| 7 +- drivers/gpu/drm/radeon/radeon_irq_kms.c| 5 + drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 4 +- drivers/hid/hid-ids.h | 1 + drivers/hid/usbhid/hid-quirks.c| 1 + drivers/md/bitmap.c| 2 + drivers/md/dm-thin-metadata.c | 4 +- drivers/md/md.c| 2 +- drivers/md/persistent-data/dm-btree-internal.h | 6 + drivers/md/persistent-data/dm-btree-remove.c | 12 +- drivers/md/persistent-data/dm-btree-spine.c| 37 drivers/md/persistent-data/dm-btree.c | 7 +- drivers/md/raid1.c | 10 +- drivers/mfd/arizona-core.c | 14 +- drivers/net/bonding/bond_main.c| 20 ++ drivers/net/ethernet/brocade/bna/bnad.c| 2 +- drivers/net/ethernet/mellanox/mlx4/eq.c| 4 +- drivers/net/ethernet/sun/niu.c | 4 +- drivers/s390/char/sclp_early.c | 1 + drivers/scsi/ipr.c | 28 ++- drivers/scsi/ipr.h | 1 + drivers/scsi/libfc/fc_exch.c | 8 +- drivers/scsi/libfc/fc_fcp.c| 19 +- drivers/scsi/libiscsi.c| 25 +-- drivers/scsi/megaraid/megaraid_sas_fusion.c| 4 +- drivers/scsi/qla2xxx/qla_isr.c | 17 +- drivers/scsi/scsi_pm.c | 22 +-- drivers/target/iscsi/iscsi_target.c| 50 - drivers/target/iscsi/iscsi_target_core.h | 1 + drivers/target/iscsi/iscsi_target_login.c | 43 ++-- drivers/target/iscsi/iscsi_ta
Re: [PATCH 5/5] virtgpu: mark as a render gpu
On Fr, 2015-09-11 at 16:32 +1000, Dave Airlie wrote: > doh, yes we need to add DRM_RENDER_ALLOW to the ioctls, can you do > that? Done. cheers, Gerd -- 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 1/2] mfd: update Intel soc PMIC header file to support Broxton WC PMIC
On Thu, 10 Sep 2015, Zha, Qipeng wrote:
> >>
> >> +#define INIT_REGMAP_IRQ(_irq, _off, _mask)\
> >> + [_irq] = { .reg_offset = (_off), .mask = (_mask) }
> >> +
>
> >No, that's not what I asked.
>
> >Either this macro is going to be useful to *everyone*, or it's probably not
> >useful to *anyone*. If it's going to exist, it should exist in the core
> >header file, not Intel's own.
>
> Jones, can we keep current change as for intel's own ? not sure if Mark
> agree to merge this macro to core regmap header file.
> Maybe some driver want to initialize regmap_irq structure with
> different/customed way.
> Thanks.
Is that what Mark said when you submitted this to him?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 0/2] pinctrl: uniphier: one fix, one addition
1/2 is a bug fix, but it is not very critical. I can wait until 4.4-rc1 if it is a hassle. 2/2 provides some more pin-mux settings. Masahiro Yamada (2): pinctrl: uniphier: fix input enable settings for PH1-sLD8 pinctrl: uniphier: add SD card pinmux settings drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c | 5 + drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c| 5 + drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c| 11 ++ drivers/pinctrl/uniphier/pinctrl-ph1-pro5.c| 5 + drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c| 230 + drivers/pinctrl/uniphier/pinctrl-proxstream2.c | 5 + 6 files changed, 148 insertions(+), 113 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: [PATCH 15/17] thermal: st: allow compile test
On Wed, 09 Sep 2015, Eduardo Valentin wrote: > Adding COMPILE_TEST flag to st driver to facilitate > maintenance. > > Cc: Zhang Rui > Cc: Nicolas Boichat > Cc: Mark Brown > Cc: Fabian Frederick > Cc: Wolfram Sang > Cc: Lee Jones > Cc: linux...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Eduardo Valentin > --- > drivers/thermal/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Sounds reasonable. So long as it's been tested and nothing breaks: Acked-by: Lee Jones > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig > index 9069cc7..d94b4e9 100644 > --- a/drivers/thermal/Kconfig > +++ b/drivers/thermal/Kconfig > @@ -350,7 +350,7 @@ source "drivers/thermal/samsung/Kconfig" > endmenu > > menu "STMicroelectronics thermal drivers" > -depends on ARCH_STI && OF > +depends on (ARCH_STI || COMPILE_TEST) && OF > source "drivers/thermal/st/Kconfig" > endmenu > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] pinctrl: uniphier: add SD card pinmux settings
Add SD card pinmux settings for PH1-LD4, PH1-Pro4, PH1-sLD8,
PH1-Pro5, ProXstream2, and PH1-LD6b SoCs.
Signed-off-by: Masahiro Yamada
---
drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c | 5 +
drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c| 5 +
drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c| 11 +++
drivers/pinctrl/uniphier/pinctrl-ph1-pro5.c| 5 +
drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c| 4
drivers/pinctrl/uniphier/pinctrl-proxstream2.c | 5 +
6 files changed, 35 insertions(+)
diff --git a/drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c
b/drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c
index 7beb87e..9e31ee0 100644
--- a/drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c
+++ b/drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c
@@ -555,6 +555,8 @@ static const unsigned usb2_pins[] = {155, 156};
static const unsigned usb2_muxvals[] = {4, 4};
static const unsigned usb2b_pins[] = {67, 68};
static const unsigned usb2b_muxvals[] = {23, 23};
+static const unsigned sd_pins[] = {44, 45, 46, 47, 48, 49, 50, 51, 52};
+static const unsigned sd_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0, 0};
static const unsigned port_range0_pins[] = {
135, 136, 137, 138, 139, 140, 141, 142, /* PORT0x */
143, 144, 145, 146, 147, 148, 149, 150, /* PORT1x */
@@ -628,6 +630,7 @@ static const struct uniphier_pinctrl_group ph1_ld4_groups[]
= {
UNIPHIER_PINCTRL_GROUP(usb1),
UNIPHIER_PINCTRL_GROUP(usb2),
UNIPHIER_PINCTRL_GROUP(usb2b),
+ UNIPHIER_PINCTRL_GROUP(sd),
UNIPHIER_PINCTRL_GROUP_GPIO_RANGE_PORT(port_range0),
UNIPHIER_PINCTRL_GROUP_GPIO_RANGE_PORT(port_range1),
UNIPHIER_PINCTRL_GROUP_GPIO_RANGE_IRQ(xirq_range0),
@@ -783,6 +786,7 @@ static const char * const uart3_groups[] = {"uart3"};
static const char * const usb0_groups[] = {"usb0"};
static const char * const usb1_groups[] = {"usb1"};
static const char * const usb2_groups[] = {"usb2", "usb2b"};
+static const char * const sd_groups[] = {"sd"};
static const char * const port_groups[] = {
"port00", "port01", "port02", "port03",
"port04", "port05", "port06", "port07",
@@ -838,6 +842,7 @@ static const struct uniphier_pinmux_function
ph1_ld4_functions[] = {
UNIPHIER_PINMUX_FUNCTION(usb0),
UNIPHIER_PINMUX_FUNCTION(usb1),
UNIPHIER_PINMUX_FUNCTION(usb2),
+ UNIPHIER_PINMUX_FUNCTION(sd),
UNIPHIER_PINMUX_FUNCTION(port),
UNIPHIER_PINMUX_FUNCTION(xirq),
};
diff --git a/drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c
b/drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c
index 9720e697..e00c067 100644
--- a/drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c
+++ b/drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c
@@ -781,6 +781,8 @@ static const unsigned usb2_pins[] = {60, 61};
static const unsigned usb2_muxvals[] = {0, 0};
static const unsigned usb3_pins[] = {62, 63};
static const unsigned usb3_muxvals[] = {0, 0};
+static const unsigned sd_pins[] = {47, 48, 49, 50, 51, 52, 53, 54, 55};
+static const unsigned sd_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0, 0};
static const unsigned port_range0_pins[] = {
127, 128, 129, 130, 131, 132, 133, 134, /* PORT0x */
135, 136, 137, 138, 139, 140, 141, 142, /* PORT1x */
@@ -876,6 +878,7 @@ static const struct uniphier_pinctrl_group
ph1_ld6b_groups[] = {
UNIPHIER_PINCTRL_GROUP(usb1),
UNIPHIER_PINCTRL_GROUP(usb2),
UNIPHIER_PINCTRL_GROUP(usb3),
+ UNIPHIER_PINCTRL_GROUP(sd),
UNIPHIER_PINCTRL_GROUP_GPIO_RANGE_PORT(port_range0),
UNIPHIER_PINCTRL_GROUP_GPIO_RANGE_PORT(port_range1),
UNIPHIER_PINCTRL_GROUP_GPIO_RANGE_IRQ(xirq),
@@ -1143,6 +1146,7 @@ static const char * const usb0_groups[] = {"usb0"};
static const char * const usb1_groups[] = {"usb1"};
static const char * const usb2_groups[] = {"usb2"};
static const char * const usb3_groups[] = {"usb3"};
+static const char * const sd_groups[] = {"sd"};
static const char * const port_groups[] = {
"port00", "port01", "port02", "port03",
"port04", "port05", "port06", "port07",
@@ -1226,6 +1230,7 @@ static const struct uniphier_pinmux_function
ph1_ld6b_functions[] = {
UNIPHIER_PINMUX_FUNCTION(usb1),
UNIPHIER_PINMUX_FUNCTION(usb2),
UNIPHIER_PINMUX_FUNCTION(usb3),
+ UNIPHIER_PINMUX_FUNCTION(sd),
UNIPHIER_PINMUX_FUNCTION(port),
UNIPHIER_PINMUX_FUNCTION(xirq),
};
diff --git a/drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c
b/drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c
index 96921e4..8b83db5 100644
--- a/drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c
+++ b/drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c
@@ -1047,6 +1047,11 @@ static const unsigned usb2_pins[] = {184, 185};
static const unsigned usb2_muxvals[] = {0, 0};
static const unsigned usb3_pins[] = {186, 187};
static const unsigned usb3_muxvals[] = {0, 0};
+static const unsigned sd_pins[] = {150, 151, 152, 153, 154, 155, 156, 157,
158};
+static const unsigned sd_muxv
[PATCH 1/2] pinctrl: uniphier: fix input enable settings for PH1-sLD8
Currently, input enable settings are missing from the PH1-sLD8
pinctrl driver. (All the entries in the pin table are set to
UNIPHIER_PIN_IECTRL_NONE).
Fill the table with correct value.
Fixes: 95372f9dc892 ("pinctrl: UniPhier: add UniPhier PH1-sLD8 pinctrl driver")
Signed-off-by: Masahiro Yamada
---
drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c | 226 ++--
1 file changed, 113 insertions(+), 113 deletions(-)
diff --git a/drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c
b/drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c
index 7e9dae5..2df8bbe 100644
--- a/drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c
+++ b/drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c
@@ -22,49 +22,49 @@
#define DRIVER_NAME "ph1-sld8-pinctrl"
static const struct pinctrl_pin_desc ph1_sld8_pins[] = {
- UNIPHIER_PINCTRL_PIN(0, "PCA00", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(0, "PCA00", 0,
15, UNIPHIER_PIN_DRV_4_8,
15, UNIPHIER_PIN_PULL_DOWN),
- UNIPHIER_PINCTRL_PIN(1, "PCA01", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(1, "PCA01", 0,
16, UNIPHIER_PIN_DRV_4_8,
16, UNIPHIER_PIN_PULL_DOWN),
- UNIPHIER_PINCTRL_PIN(2, "PCA02", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(2, "PCA02", 0,
17, UNIPHIER_PIN_DRV_4_8,
17, UNIPHIER_PIN_PULL_DOWN),
- UNIPHIER_PINCTRL_PIN(3, "PCA03", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(3, "PCA03", 0,
18, UNIPHIER_PIN_DRV_4_8,
18, UNIPHIER_PIN_PULL_DOWN),
- UNIPHIER_PINCTRL_PIN(4, "PCA04", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(4, "PCA04", 0,
19, UNIPHIER_PIN_DRV_4_8,
19, UNIPHIER_PIN_PULL_DOWN),
- UNIPHIER_PINCTRL_PIN(5, "PCA05", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(5, "PCA05", 0,
20, UNIPHIER_PIN_DRV_4_8,
20, UNIPHIER_PIN_PULL_DOWN),
- UNIPHIER_PINCTRL_PIN(6, "PCA06", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(6, "PCA06", 0,
21, UNIPHIER_PIN_DRV_4_8,
21, UNIPHIER_PIN_PULL_DOWN),
- UNIPHIER_PINCTRL_PIN(7, "PCA07", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(7, "PCA07", 0,
22, UNIPHIER_PIN_DRV_4_8,
22, UNIPHIER_PIN_PULL_DOWN),
- UNIPHIER_PINCTRL_PIN(8, "PCA08", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(8, "PCA08", 0,
23, UNIPHIER_PIN_DRV_4_8,
23, UNIPHIER_PIN_PULL_DOWN),
- UNIPHIER_PINCTRL_PIN(9, "PCA09", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(9, "PCA09", 0,
24, UNIPHIER_PIN_DRV_4_8,
24, UNIPHIER_PIN_PULL_DOWN),
- UNIPHIER_PINCTRL_PIN(10, "PCA10", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(10, "PCA10", 0,
25, UNIPHIER_PIN_DRV_4_8,
25, UNIPHIER_PIN_PULL_DOWN),
- UNIPHIER_PINCTRL_PIN(11, "PCA11", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(11, "PCA11", 0,
26, UNIPHIER_PIN_DRV_4_8,
26, UNIPHIER_PIN_PULL_DOWN),
- UNIPHIER_PINCTRL_PIN(12, "PCA12", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(12, "PCA12", 0,
27, UNIPHIER_PIN_DRV_4_8,
27, UNIPHIER_PIN_PULL_DOWN),
- UNIPHIER_PINCTRL_PIN(13, "PCA13", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(13, "PCA13", 0,
28, UNIPHIER_PIN_DRV_4_8,
28, UNIPHIER_PIN_PULL_DOWN),
- UNIPHIER_PINCTRL_PIN(14, "PCA14", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(14, "PCA14", 0,
29, UNIPHIER_PIN_DRV_4_8,
29, UNIPHIER_PIN_PULL_DOWN),
UNIPHIER_PINCTRL_PIN(15, "XNFRE_GB", UNIPHIER_PIN_IECTRL_NONE,
@@ -118,199 +118,199 @@ static const struct pinctrl_pin_desc ph1_sld8_pins[] = {
UNIPHIER_PINCTRL_PIN(31, "NFD7_GB", UNIPHIER_PIN_IECTRL_NONE,
36, UNIPHIER_PIN_DRV_8_12_16_20,
128, UNIPHIER_PIN_PULL_UP),
- UNIPHIER_PINCTRL_PIN(32, "SDCLK", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(32, "SDCLK", 8,
40, UNIPHIER_PIN_DRV_8_12_16_20,
-1, UNIPHIER_PIN_PULL_NONE),
- UNIPHIER_PINCTRL_PIN(33, "SDCMD", UNIPHIER_PIN_IECTRL_NONE,
+ UNIPHIER_PINCTRL_PIN(33, "SDCMD", 8,
44, UNIPHIER_PIN_DRV_8_12_16_20,
-1, UNIPHIER_PIN_PULL_NONE),
- UNIPHIER_PINCTRL_PIN
Re: [PATCH V4 2/4] kvm: fix double free for fast mmio eventfd
On 09/11/2015 03:46 PM, Cornelia Huck wrote:
> On Fri, 11 Sep 2015 11:17:35 +0800
> Jason Wang wrote:
>
>> We register wildcard mmio eventfd on two buses, one for KVM_MMIO_BUS
>> and another is KVM_FAST_MMIO_BUS but with a single iodev
>> instance. This will lead an issue: kvm_io_bus_destroy() knows nothing
>> about the devices on two buses points to a single dev. Which will lead
> s/points/pointing/
Will fix this in V5.
>> double free[1] during exit. Fixing this by using allocate two
> s/using allocate/allocating/
Will fix this in V5.
>
>> instances of iodevs then register one on KVM_MMIO_BUS and another on
>> KVM_FAST_MMIO_BUS.
>>
> (...)
>
>> @@ -929,8 +878,66 @@ kvm_deassign_ioeventfd_idx(struct kvm *kvm, enum
>> kvm_bus bus_idx,
>> static int kvm_deassign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd
>> *args)
>> {
>> enum kvm_bus bus_idx = ioeventfd_bus_from_flags(args->flags);
>> +int ret = kvm_deassign_ioeventfd_idx(kvm, bus_idx, args);
>> +
>> +if (!args->len)
>> +kvm_deassign_ioeventfd_idx(kvm, KVM_FAST_MMIO_BUS, args);
> I think it would be good to explicitly check for bus_idx ==
> KVM_MMIO_BUS here.
Ok.
>
>> +
>> +return ret;
>> +}
>>
>> -return kvm_deassign_ioeventfd_idx(kvm, bus_idx, args);
>> +static int
>> +kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
>> +{
>> +enum kvm_bus bus_idx;
>> +int ret;
>> +
>> +bus_idx = ioeventfd_bus_from_flags(args->flags);
>> +/* must be natural-word sized, or 0 to ignore length */
>> +switch (args->len) {
>> +case 0:
>> +case 1:
>> +case 2:
>> +case 4:
>> +case 8:
>> +break;
>> +default:
>> +return -EINVAL;
>> +}
>> +
>> +/* check for range overflow */
>> +if (args->addr + args->len < args->addr)
>> +return -EINVAL;
>> +
>> +/* check for extra flags that we don't understand */
>> +if (args->flags & ~KVM_IOEVENTFD_VALID_FLAG_MASK)
>> +return -EINVAL;
>> +
>> +/* ioeventfd with no length can't be combined with DATAMATCH */
>> +if (!args->len &&
>> +args->flags & (KVM_IOEVENTFD_FLAG_PIO |
>> + KVM_IOEVENTFD_FLAG_DATAMATCH))
>> +return -EINVAL;
>> +
>> +ret = kvm_assign_ioeventfd_idx(kvm, bus_idx, args);
>> +if (ret)
>> +goto fail;
>> +
>> +/* When length is ignored, MMIO is also put on a separate bus, for
>> + * faster lookups.
>> + */
>> +if (!args->len && !(args->flags & KVM_IOEVENTFD_FLAG_PIO)) {
> Dito on a positive check for bus_idx == KVM_MMIO_BUS.
I was thinking maybe this should be done in a separate patch on top.
What's your opinion?
>> +ret = kvm_assign_ioeventfd_idx(kvm, KVM_FAST_MMIO_BUS, args);
>> +if (ret < 0)
>> +goto fast_fail;
>> +}
>> +
>> +return 0;
>> +
>> +fast_fail:
>> +kvm_deassign_ioeventfd(kvm, args);
> Shouldn't you use kvm_deassign_ioeventfd(kvm, bus_idx, args) here?
Actually, it's the same. (the deassign of fast mmio will return -ENOENT
and will be ignored.) But I admit do what you suggested here is better.
Will do this.
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 V4 3/4] kvm: fix zero length mmio searching
On 09/11/2015 04:31 PM, Cornelia Huck wrote:
> On Fri, 11 Sep 2015 10:26:41 +0200
> Paolo Bonzini wrote:
>
>> On 11/09/2015 05:17, Jason Wang wrote:
>>> + int len = r2->len ? r1->len : 0;
>>> +
>>> if (r1->addr < r2->addr)
>>> return -1;
>>> - if (r1->addr + r1->len > r2->addr + r2->len)
>>> + if (r1->addr + len > r2->addr + r2->len)
>>> return 1;
>> Perhaps better:
>>
>> gpa_t addr1 = r1->addr;
>> gpa_t addr2 = r2->addr;
>>
>> if (addr1 < addr2)
>> return -1;
>>
>> /* If r2->len == 0, match the exact address. If r2->len != 0,
>> * accept any overlapping write. Any order is acceptable for
>> * overlapping ranges, because kvm_io_bus_get_first_dev ensures
>> * we process all of them.
>> */
>> if (r2->len) {
>> addr1 += r1->len;
>> addr2 += r2->len;
>> }
>>
>> if (addr1 > addr2)
>> return 1;
>>
>> return 0;
>>
> +1 to documenting what the semantics are :)
>
Right, better. Will fix this in V5.
--
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/4] Fast MMIO eventfd fixes
On 09/11/2015 04:33 PM, Paolo Bonzini wrote: > > On 11/09/2015 10:15, Michael S. Tsirkin wrote: >> I think we should add a capability for fast mmio. >> This way, userspace can avoid crashing buggy kernels. > I agree. > > Paolo Right, then qemu will use datamatch eventfd if kenrel dost not have the capability. 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 2/2] [media] media-device: split media initialization and registration
Hi Mauro, Mauro Carvalho Chehab wrote: > Em Fri, 11 Sep 2015 09:31:36 +0200 > Javier Martinez Canillas escreveu: > >> Hello Sakari, >> >> On 09/11/2015 07:51 AM, Sakari Ailus wrote: >>> Hi Javier, >>> >>> Javier Martinez Canillas wrote: Hello Sakari, On 09/10/2015 07:14 PM, Sakari Ailus wrote: > Hi Javier, > > Thanks for the set! A few comments below. > Thanks to you for your feedback. > Javier Martinez Canillas wrote: >> The media device node is registered and so made visible to user-space >> before entities are registered and links created which means that the >> media graph obtained by user-space could be only partially enumerated >> if that happens too early before all the graph has been created. >> >> To avoid this race condition, split the media init and registration >> in separate functions and only register the media device node when >> all the pending subdevices have been registered, either explicitly >> by the driver or asynchronously using v4l2_async_register_subdev(). >> >> Also, add a media_entity_cleanup() function that will destroy the >> graph_mutex that is initialized in media_entity_init(). >> >> Suggested-by: Sakari Ailus >> Signed-off-by: Javier Martinez Canillas >> >> --- >> >> drivers/media/common/siano/smsdvb-main.c | 1 + >> drivers/media/media-device.c | 38 >> +++ >> drivers/media/platform/exynos4-is/media-dev.c | 12 ++--- >> drivers/media/platform/omap3isp/isp.c | 11 +--- >> drivers/media/platform/s3c-camif/camif-core.c | 13 ++--- >> drivers/media/platform/vsp1/vsp1_drv.c| 19 ++ >> drivers/media/platform/xilinx/xilinx-vipp.c | 11 +--- >> drivers/media/usb/au0828/au0828-core.c| 26 +- >> drivers/media/usb/cx231xx/cx231xx-cards.c | 22 +++- >> drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 11 +--- >> drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 13 ++--- >> drivers/media/usb/siano/smsusb.c | 14 -- >> drivers/media/usb/uvc/uvc_driver.c| 9 +-- >> include/media/media-device.h | 2 ++ >> 14 files changed, 156 insertions(+), 46 deletions(-) >> >> diff --git a/drivers/media/common/siano/smsdvb-main.c >> b/drivers/media/common/siano/smsdvb-main.c >> index ab345490a43a..8a1ea2192439 100644 >> --- a/drivers/media/common/siano/smsdvb-main.c >> +++ b/drivers/media/common/siano/smsdvb-main.c >> @@ -617,6 +617,7 @@ static void smsdvb_media_device_unregister(struct >> smsdvb_client_t *client) >> if (!coredev->media_dev) >> return; >> media_device_unregister(coredev->media_dev); >> +media_device_cleanup(coredev->media_dev); >> kfree(coredev->media_dev); >> coredev->media_dev = NULL; >> #endif >> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c >> index 745defb34b33..a8beb0b445a6 100644 >> --- a/drivers/media/media-device.c >> +++ b/drivers/media/media-device.c >> @@ -526,7 +526,7 @@ static void media_device_release(struct >> media_devnode *mdev) >> } >> >> /** >> - * media_device_register - register a media device >> + * media_device_init() - initialize a media device >>* @mdev:The media device >>* >>* The caller is responsible for initializing the media device before >> @@ -534,12 +534,11 @@ static void media_device_release(struct >> media_devnode *mdev) >>* >>* - dev must point to the parent device >>* - model must be filled with the device model name >> + * >> + * returns zero on success or a negative error code. >>*/ >> -int __must_check __media_device_register(struct media_device *mdev, >> - struct module *owner) >> +int __must_check media_device_init(struct media_device *mdev) > > I think I suggested making media_device_init() return void as the only > remaining source of errors would be driver bugs. > Yes you did and I think I explained why I preferred to leave it as is and I thought we agreed :) >>> >>> I thought we agreed, too. But my understanding was that the agreement was >>> different. ;-) >>> >> >> Fair enough :) >> Currently media_device_register() is failing gracefully if a buggy driver is not setting mdev->dev. So changing media_device_init() to return void instead, would be a semantic change and if drivers are not checking that anymore, can lead to NULL pointer dereference bugs. >>> >>> Do we have such drivers? Would they ever have worked in the first place, as >>> media device registration would have failed? > > Actually we do. Th
Re: [PATCH v4 7/8] mfd: 88pm860x: Move over to new I2C device .probe() call
On Wed, 09 Sep 2015, Kieran Bingham wrote:
> From: Lee Jones
>
> As part of an effort to rid the mostly unused second parameter for I2C
> related .probe() functions and to conform to other existing frameworks
> we're moving over to a temporary replacement .probe() call-back.
>
> Acked-by: Grant Likely
> Signed-off-by: Lee Jones
SoB?
> ---
> drivers/mfd/88pm860x-core.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mfd/88pm860x-core.c b/drivers/mfd/88pm860x-core.c
> index 3269a99..a499d70 100644
> --- a/drivers/mfd/88pm860x-core.c
> +++ b/drivers/mfd/88pm860x-core.c
> @@ -1130,8 +1130,7 @@ static int pm860x_dt_init(struct device_node *np,
> return 0;
> }
>
> -static int pm860x_probe(struct i2c_client *client,
> - const struct i2c_device_id *id)
> +static int pm860x_probe(struct i2c_client *client)
> {
> struct pm860x_platform_data *pdata = dev_get_platdata(&client->dev);
> struct device_node *node = client->dev.of_node;
> @@ -1257,7 +1256,7 @@ static struct i2c_driver pm860x_driver = {
> .pm = &pm860x_pm_ops,
> .of_match_table = pm860x_dt_ids,
> },
> - .probe = pm860x_probe,
> + .probe2 = pm860x_probe,
> .remove = pm860x_remove,
> .id_table = pm860x_id_table,
> };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 8/8] mfd: as3722: Rid driver of superfluous I2C device ID structure
On Wed, 09 Sep 2015, Kieran Bingham wrote:
> From: Lee Jones
>
> Also remove unused second probe() parameter 'i2c_device_id'.
>
> Acked-by: Grant Likely
> Signed-off-by: Lee Jones
SoB?
> ---
> drivers/mfd/as3722.c | 12 ++--
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mfd/as3722.c b/drivers/mfd/as3722.c
> index 924ea90..6ac4be3 100644
> --- a/drivers/mfd/as3722.c
> +++ b/drivers/mfd/as3722.c
> @@ -354,8 +354,7 @@ static int as3722_i2c_of_probe(struct i2c_client *i2c,
> return 0;
> }
>
> -static int as3722_i2c_probe(struct i2c_client *i2c,
> - const struct i2c_device_id *id)
> +static int as3722_i2c_probe(struct i2c_client *i2c)
> {
> struct as3722 *as3722;
> unsigned long irq_flags;
> @@ -428,20 +427,13 @@ static const struct of_device_id as3722_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, as3722_of_match);
>
> -static const struct i2c_device_id as3722_i2c_id[] = {
> - { "as3722", 0 },
> - {},
> -};
> -MODULE_DEVICE_TABLE(i2c, as3722_i2c_id);
> -
> static struct i2c_driver as3722_i2c_driver = {
> .driver = {
> .name = "as3722",
> .of_match_table = as3722_of_match,
> },
> - .probe = as3722_i2c_probe,
> + .probe2 = as3722_i2c_probe,
> .remove = as3722_i2c_remove,
> - .id_table = as3722_i2c_id,
> };
>
> module_i2c_driver(as3722_i2c_driver);
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] drm/nouveau: fix memory leak
If pm_runtime_get_sync() we were going to "out" but we missed freeing
vma.
Signed-off-by: Sudip Mukherjee
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 2c99815..c05b2f7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -84,8 +84,10 @@ nouveau_gem_object_open(struct drm_gem_object *gem, struct
drm_file *file_priv)
}
ret = pm_runtime_get_sync(dev);
- if (ret < 0 && ret != -EACCES)
+ if (ret < 0 && ret != -EACCES) {
+ kfree(vma);
goto out;
+ }
ret = nouveau_bo_vma_add(nvbo, cli->vm, vma);
if (ret)
--
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 v4 4/8] i2c: Make I2C ID tables non-mandatory for DT'ed devices
On Wed, 09 Sep 2015, Kieran Bingham wrote: > From: Lee Jones > > Currently the I2C framework insists on devices supplying an I2C ID > table. Many of the devices which do so unnecessarily adding quite a > few wasted lines to kernel code. This patch allows drivers a means > to 'not' supply the aforementioned table and match on DT match tables > instead. > > Acked-by: Grant Likely > Signed-off-by: Lee Jones SoB? > --- > drivers/i2c/i2c-core.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c > index 94ca76e..2ebc64d 100644 > --- a/drivers/i2c/i2c-core.c > +++ b/drivers/i2c/i2c-core.c > @@ -468,7 +468,7 @@ static int i2c_device_match(struct device *dev, struct > device_driver *drv) > > > /* Attempt an OF style match */ > - if (of_driver_match_device(dev, drv)) > + if (i2c_of_match_device(drv->of_match_table, client)) > return 1; > > /* Then ACPI style match */ > @@ -657,7 +657,15 @@ static int i2c_device_probe(struct device *dev) > } > > driver = to_i2c_driver(dev->driver); > - if (!driver->probe || !driver->id_table) > + if (!driver->probe) > + return -EINVAL; > + > + /* > + * An I2C ID table is not mandatory, if and only if, a suitable Device > + * Tree match table entry is supplied for the probing device. > + */ > + if (!driver->id_table && > + !i2c_of_match_device(dev->driver->of_match_table, client)) > return -ENODEV; > > if (!device_can_wakeup(&client->dev)) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 5/8] i2c: Export i2c_match_id() for direct use by device drivers
On Wed, 09 Sep 2015, Kieran Bingham wrote:
> From: Lee Jones
>
> When there was no other way to match a I2C device to driver i2c_match_id()
> was exclusively used. However, now there are other types of tables which
> are commonly supplied, matching on an i2c_device_id table is used less
> frequently. Instead of _always_ calling i2c_match_id() from within the
> framework, we only need to do so from drivers which have no other way of
> matching. This patch makes i2c_match_id() available to the aforementioned
> device drivers.
>
> Acked-by: Grant Likely
> Signed-off-by: Lee Jones
SoB?
> ---
> drivers/i2c/i2c-core.c | 3 ++-
> include/linux/i2c.h| 2 ++
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 2ebc64d..0e40136 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -447,7 +447,7 @@ static inline int acpi_i2c_install_space_handler(struct
> i2c_adapter *adapter)
>
> /* -
> */
>
> -static const struct i2c_device_id *i2c_match_id(const struct i2c_device_id
> *id,
> +const struct i2c_device_id *i2c_match_id(const struct i2c_device_id *id,
> const struct i2c_client *client)
> {
> if (!(id && client))
> @@ -460,6 +460,7 @@ static const struct i2c_device_id *i2c_match_id(const
> struct i2c_device_id *id,
> }
> return NULL;
> }
> +EXPORT_SYMBOL_GPL(i2c_match_id);
>
> static int i2c_device_match(struct device *dev, struct device_driver *drv)
> {
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index 48bbbab..126585c 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -232,6 +232,8 @@ struct i2c_client {
>
> extern struct i2c_client *i2c_verify_client(struct device *dev);
> extern struct i2c_adapter *i2c_verify_adapter(struct device *dev);
> +extern const struct i2c_device_id *i2c_match_id(const struct i2c_device_id
> *id,
> + const struct i2c_client *client);
>
> static inline struct i2c_client *kobj_to_i2c_client(struct kobject *kobj)
> {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 3/8] i2c: Match using traditional OF methods, then by vendor-less compatible strings
On Wed, 09 Sep 2015, Kieran Bingham wrote:
> From: Lee Jones
>
> This function provides a single call for all I2C devices which need to
> match firstly using traditional OF means i.e by of_node, then if that
> fails we attempt to match using the supplied I2C client name with a
> list of supplied compatible strings with the ',' string
> removed. The latter is required due to the unruly naming conventions
> used currently by I2C devices.
>
> Acked-by: Grant Likely
> Signed-off-by: Lee Jones
SoB?
> ---
> drivers/i2c/i2c-core.c | 16
> include/linux/i2c.h| 12
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 0788c1f..94ca76e 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -1394,6 +1394,22 @@ i2c_of_match_device_strip_vendor(const struct
> of_device_id *matches,
> return NULL;
> }
>
> +const struct of_device_id
> +*i2c_of_match_device(const struct of_device_id *matches,
> + struct i2c_client *client)
> +{
> + const struct of_device_id *match;
> +
> + if (!(client && matches))
> + return NULL;
> +
> + match = of_match_device(matches, &client->dev);
> + if (match)
> + return match;
> +
> + return i2c_of_match_device_strip_vendor(matches, client);
> +}
> +EXPORT_SYMBOL_GPL(i2c_of_match_device);
> #else
> static void of_i2c_register_devices(struct i2c_adapter *adap) { }
> #endif /* CONFIG_OF */
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index e83a738..48bbbab 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -638,6 +638,10 @@ extern struct i2c_client
> *of_find_i2c_device_by_node(struct device_node *node);
> /* must call put_device() when done with returned i2c_adapter device */
> extern struct i2c_adapter *of_find_i2c_adapter_by_node(struct device_node
> *node);
>
> +extern const struct of_device_id
> +*i2c_of_match_device(const struct of_device_id *matches,
> + struct i2c_client *client);
> +
> #else
>
> static inline struct i2c_client *of_find_i2c_device_by_node(struct
> device_node *node)
> @@ -649,6 +653,14 @@ static inline struct i2c_adapter
> *of_find_i2c_adapter_by_node(struct device_node
> {
> return NULL;
> }
> +
> +const struct of_device_id
> +*i2c_of_match_device(const struct of_device_id *matches,
> + struct i2c_client *client)
> +{
> + return NULL;
> +}
> +
> #endif /* CONFIG_OF */
>
> #endif /* _LINUX_I2C_H */
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 1/8] i2c: Add pointer dereference protection to i2c_match_id()
On Wed, 09 Sep 2015, Kieran Bingham wrote:
> From: Lee Jones
>
> Here we're providing dereference protection for i2c_match_id(), which
> saves us having to do it each time it's called. We're also stripping
> out the (now) needless checks in i2c_device_match(). This patch paves
> the way for other, similar code trimming.
>
> Acked-by: Grant Likely
> Signed-off-by: Lee Jones
SoB?
> ---
> drivers/i2c/i2c-core.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index c83e4d1..30d8a77 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -450,6 +450,9 @@ static inline int acpi_i2c_install_space_handler(struct
> i2c_adapter *adapter)
> static const struct i2c_device_id *i2c_match_id(const struct i2c_device_id
> *id,
> const struct i2c_client *client)
> {
> + if (!(id && client))
> + return NULL;
> +
> while (id->name[0]) {
> if (strcmp(client->name, id->name) == 0)
> return id;
> @@ -463,8 +466,6 @@ static int i2c_device_match(struct device *dev, struct
> device_driver *drv)
> struct i2c_client *client = i2c_verify_client(dev);
> struct i2c_driver *driver;
>
> - if (!client)
> - return 0;
>
> /* Attempt an OF style match */
> if (of_driver_match_device(dev, drv))
> @@ -475,9 +476,10 @@ static int i2c_device_match(struct device *dev, struct
> device_driver *drv)
> return 1;
>
> driver = to_i2c_driver(drv);
> - /* match on an id table if there is one */
> - if (driver->id_table)
> - return i2c_match_id(driver->id_table, client) != NULL;
> +
> + /* Finally an I2C match */
> + if (i2c_match_id(driver->id_table, client))
> + return 1;
>
> return 0;
> }
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] bnx2x: use ktime_get_seconds() for timestamp
commit c48f350ff5e7 "bnx2x: Add MFW dump support" added the
bnx2x_update_mfw_dump() function that reads the current time and stores
it in a 32-bit field that gets passed into a buffer in a fixed format.
This is potentially broken when the epoch overflows in 2038, and
otherwise overflows in 2106. As we're trying to avoid uses of
struct timeval for this reason, I noticed the addition of this
function, and tried to rewrite it in a way that is more explicit
about the overflow and that will keep working once we deprecate
struct timeval.
I assume that it is not possible to change the ABI any more, otherwise
we should try to use a 64-bit field for the seconds right away.
Signed-off-by: Arnd Bergmann
Cc: Yuval Mintz
Cc: Ariel Elior
---
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index e3da2bddf143..89a174fa1300 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -3705,16 +3705,14 @@ out:
void bnx2x_update_mfw_dump(struct bnx2x *bp)
{
- struct timeval epoc;
u32 drv_ver;
u32 valid_dump;
if (!SHMEM2_HAS(bp, drv_info))
return;
- /* Update Driver load time */
- do_gettimeofday(&epoc);
- SHMEM2_WR(bp, drv_info.epoc, epoc.tv_sec);
+ /* Update Driver load time, possibly broken in y2038 */
+ SHMEM2_WR(bp, drv_info.epoc, (u32)ktime_get_real_seconds());
drv_ver = bnx2x_update_mng_version_utility(DRV_MODULE_VERSION, true);
SHMEM2_WR(bp, drv_info.drv_ver, drv_ver);
--
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/
