Reply...
Hello,
My name is Ms. Reem Ebrahim Al-Hashimi, I am the "Minister of state and
Petroleum" also "Minister of
State for International Cooperation" in UAE. I write to you on behalf of my
other "three (3)
colleagues" who has approved me to solicit for your "partnership in claiming of
{us$90=Million}"
from a Financial Home in Cambodia on their behalf and for our "Mutual Benefits".
The Fund {us$90=Million} is our "outstanding share from the Over-invoiced"
Oil/Gas deal with
Cambodian/Vietnam Government within 2013/2014, however, We don't want our
government to know about
the fund. If this proposal interests you, let me know, by sending me an email
and I will send to you
detailed information on how this business would be successfully transacted. Be
informed that nobody
knows about the secret of this fund except us, and we know how to carry out the
entire transaction.
So I am compelled to ask, that you will stand on our behalf and receive this
fund into any account
that is solely controlled by you.
We will compensate you with 30% of the total amount involved as gratification
for being our partner
in this transaction. Reply to my private email as stated:
reemal-hash...@yandex.com
Regards,
Ms. Reem Ebrahim Al-Hashimi.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
The Fund
Hello,
My name is Ms. Reem Ebrahim Al-Hashimi, I am the "Minister of state and
Petroleum" also "Minister of State for International Cooperation" in UAE. I
write to solicit for your partnership in claiming of {us$90=Million} from a
Financial Home in Cambodia.
The Fund {us$90=Million} is my share from the (Over-invoiced) Oil/Gas deal with
Cambodia/Vietnam Government within 2013/2014, however, I don't want my
government to know about the fund. If this proposal interests you, let me know
by sending me an email and I will send to you detailed Information on how this
business would be successfully transacted. Be informed that nobody knows about
the secret of this fund except me and I know how to carry out the entire
transaction. So I am compelled to ask that you will stand on my behalf and
receive this fund into any account that is solely controlled by you.
I will compensate you with 30% of the total amount involved as gratification
for being my partner in the transfer. Reply to my private email as stated:
reemal-hash...@yandex.com
Regards,
Ms. Reem Ebrahim Al-Hashimi.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Investment/Donation For Covid19
Greetings, My name is Sofia Guang Blaschke. I am the wife of the owner of Luen Yick Mfg Co Ltd Wuhan China.I am in hospital suffering from covid 19 (corona virus).I am in the intensive care unit and the doctor told me that I may not survive.My husband died of covid 19 and his wish before he died is to help other people affected by covid19 and invest in the supply of personal protective equipment (PPE) to help stop the spreading of the Covid19 virus. However, I came across your details on the internet while searching for a reliable person to help me to achieve my husband wish by helping people affected by covid19 and invest in your country.It will be in my interest to transfer this fund worth $5,000,000.00 (Five million dollars) in a bank account for you to support the people affected by Covid19 in your country and invest the rest.Can you be of help? If you are interested and ready to help please contact our financial officer so that she can guide you through to receive the money .See her contact details below: Name Chen Shun Company -Lexin Financial Consultant Direct phone: +86 755 3637 8008 email-lexinfinancialconsult...@aliyun.com Address-26th Floor No. 3099 Keyuan South Road Nanshan District Shenzhen 518052 China Best Regards Sofia Guang Luen Yick Mfg Co Ltd Wuhan China 10/F Flat F Block 2, Kings-ford Ind'L Building 26-32 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [greybus-dev] [PATCH v4 1/7] staging: greybus: audio: Update snd_jack FW usage as per new APIs
On Wed, Aug 5, 2020 at 6:35 PM Alex Elder wrote:
>
> On 7/9/20 5:27 AM, Vaibhav Agarwal wrote:
> > snd_soc_jack APIs are modified in recent kernel versions. This patch
> > updates the codec driver to resolve the compilation errors related to
> > jack framework.
>
> Greg has already accepted this series so I won't review this now. But
> I still wanted to provide this comment.
>
> It would be helpful in the future to provide a little more information
> about the nature of the changes to these APIs. As a reviewer I had to
> go track them down to get a little more context about what you are doing
> here. So you could say something like:
>
> Audio jacks are now registered at the card level rather than being
> associated with a CODEC. The new card-based API allows a jack's pins
> to be supplied when the jack is first registered. See: 970939964c26
> ("ASoC: Allow to register jacks at the card level")
>
> In other words, don't just say "the APIs changed," say "here is how
> the APIs have changed." This kind of introduction can be very helpful
> and time saving for your reviewers.
>
Thanks for the feedback Alex. I'll take care of the commit message while
sharing similar patches.
--
vaibhav
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH][next] staging: wfx: fix a handful of spelling mistakes
On 8/5/20 7:23 AM, Colin King wrote:
> From: Colin Ian King
>
> There are various spelling mistakes in comments and error messages.
> Fix these.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/staging/wfx/data_rx.c | 2 +-
> drivers/staging/wfx/data_tx.c | 2 +-
> drivers/staging/wfx/debug.c | 4 ++--
> drivers/staging/wfx/hif_rx.c | 2 +-
> drivers/staging/wfx/hif_tx.c | 4 ++--
> drivers/staging/wfx/main.c| 2 +-
> drivers/staging/wfx/main.h| 2 +-
> drivers/staging/wfx/sta.c | 2 +-
> 8 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/wfx/debug.c b/drivers/staging/wfx/debug.c
> index 3f1712b7c919..e396f18747d1 100644
> --- a/drivers/staging/wfx/debug.c
> +++ b/drivers/staging/wfx/debug.c
> @@ -299,7 +299,7 @@ static ssize_t wfx_send_hif_msg_read(struct file *file,
> char __user *user_buf,
> return ret;
> if (context->ret < 0)
> return context->ret;
> - // Be carefull, write() is waiting for a full message while read()
> + // Be careful, write() is waiting for a full message while read()
> // only return a payload
only returns a payload
> if (copy_to_user(user_buf, context->reply, count))
> return -EFAULT;
> diff --git a/drivers/staging/wfx/hif_tx.c b/drivers/staging/wfx/hif_tx.c
> index 5110f9b93762..11fbdb5fcecc 100644
> --- a/drivers/staging/wfx/hif_tx.c
> +++ b/drivers/staging/wfx/hif_tx.c
> @@ -125,7 +125,7 @@ int wfx_cmd_send(struct wfx_dev *wdev, struct hif_msg
> *request,
>
> // This function is special. After HIF_REQ_ID_SHUT_DOWN, chip won't reply to
> any
> // request anymore. We need to slightly hack struct wfx_hif_cmd for that
> job. Be
> -// carefull to only call this funcion during device unregister.
> +// carefull to only call this function during device unregister.
careful
> int hif_shutdown(struct wfx_dev *wdev)
> {
> int ret;
> diff --git a/drivers/staging/wfx/main.h b/drivers/staging/wfx/main.h
> index c59d375dd3ad..63138777e72a 100644
> --- a/drivers/staging/wfx/main.h
> +++ b/drivers/staging/wfx/main.h
> @@ -19,7 +19,7 @@ struct wfx_dev;
> struct hwbus_ops;
>
> struct wfx_platform_data {
> - /* Keyset and ".sec" extention will appended to this string */
> + /* Keyset and ".sec" extension will appended to this string */
will be appended
> const char *file_fw;
> const char *file_pds;
> struct gpio_desc *gpio_wakeup;
--
~Randy
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH][next] staging: wfx: fix a handful of spelling mistakes
From: Colin Ian King
There are various spelling mistakes in comments and error messages.
Fix these.
Signed-off-by: Colin Ian King
---
drivers/staging/wfx/data_rx.c | 2 +-
drivers/staging/wfx/data_tx.c | 2 +-
drivers/staging/wfx/debug.c | 4 ++--
drivers/staging/wfx/hif_rx.c | 2 +-
drivers/staging/wfx/hif_tx.c | 4 ++--
drivers/staging/wfx/main.c| 2 +-
drivers/staging/wfx/main.h| 2 +-
drivers/staging/wfx/sta.c | 2 +-
8 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/wfx/data_rx.c b/drivers/staging/wfx/data_rx.c
index 6fb078880742..7fcbbfc53416 100644
--- a/drivers/staging/wfx/data_rx.c
+++ b/drivers/staging/wfx/data_rx.c
@@ -73,7 +73,7 @@ void wfx_rx_cb(struct wfx_vif *wvif,
if (arg->rx_flags.encryp)
hdr->flag |= RX_FLAG_DECRYPTED;
- // Block ack negociation is offloaded by the firmware. However,
+ // Block ack negotiation is offloaded by the firmware. However,
// re-ordering must be done by the mac80211.
if (ieee80211_is_action(frame->frame_control) &&
mgmt->u.action.category == WLAN_CATEGORY_BACK &&
diff --git a/drivers/staging/wfx/data_tx.c b/drivers/staging/wfx/data_tx.c
index 3acf4eb0214d..41f9afd41e14 100644
--- a/drivers/staging/wfx/data_tx.c
+++ b/drivers/staging/wfx/data_tx.c
@@ -234,7 +234,7 @@ static void wfx_tx_fixup_rates(struct ieee80211_tx_rate
*rates)
int i;
bool finished;
- // Firmware is not able to mix rates with differents flags
+ // Firmware is not able to mix rates with different flags
for (i = 0; i < IEEE80211_TX_MAX_RATES; i++) {
if (rates[0].flags & IEEE80211_TX_RC_SHORT_GI)
rates[i].flags |= IEEE80211_TX_RC_SHORT_GI;
diff --git a/drivers/staging/wfx/debug.c b/drivers/staging/wfx/debug.c
index 3f1712b7c919..e396f18747d1 100644
--- a/drivers/staging/wfx/debug.c
+++ b/drivers/staging/wfx/debug.c
@@ -267,7 +267,7 @@ static ssize_t wfx_send_hif_msg_write(struct file *file,
if (count < sizeof(struct hif_msg))
return -EINVAL;
- // wfx_cmd_send() chekc that reply buffer is wide enough, but do not
+ // wfx_cmd_send() checks that reply buffer is wide enough, but does not
// return precise length read. User have to know how many bytes should
// be read. Filling reply buffer with a memory pattern may help user.
memset(context->reply, 0xFF, sizeof(context->reply));
@@ -299,7 +299,7 @@ static ssize_t wfx_send_hif_msg_read(struct file *file,
char __user *user_buf,
return ret;
if (context->ret < 0)
return context->ret;
- // Be carefull, write() is waiting for a full message while read()
+ // Be careful, write() is waiting for a full message while read()
// only return a payload
if (copy_to_user(user_buf, context->reply, count))
return -EFAULT;
diff --git a/drivers/staging/wfx/hif_rx.c b/drivers/staging/wfx/hif_rx.c
index cc7c0cf226ba..1d32973d8ec1 100644
--- a/drivers/staging/wfx/hif_rx.c
+++ b/drivers/staging/wfx/hif_rx.c
@@ -118,7 +118,7 @@ static int hif_keys_indication(struct wfx_dev *wdev,
// SL_PUB_KEY_EXCHANGE_STATUS_SUCCESS is used by legacy secure link
if (body->status && body->status != HIF_STATUS_SLK_NEGO_SUCCESS)
- dev_warn(wdev->dev, "secure link negociation error\n");
+ dev_warn(wdev->dev, "secure link negotiation error\n");
memcpy(pubkey, body->ncp_pub_key, sizeof(pubkey));
memreverse(pubkey, sizeof(pubkey));
wfx_sl_check_pubkey(wdev, pubkey, body->ncp_pub_key_mac);
diff --git a/drivers/staging/wfx/hif_tx.c b/drivers/staging/wfx/hif_tx.c
index 5110f9b93762..11fbdb5fcecc 100644
--- a/drivers/staging/wfx/hif_tx.c
+++ b/drivers/staging/wfx/hif_tx.c
@@ -78,7 +78,7 @@ int wfx_cmd_send(struct wfx_dev *wdev, struct hif_msg
*request,
wfx_bh_request_tx(wdev);
- // NOTE: no timeout is catched async is enabled
+ // NOTE: no timeout is caught async is enabled
if (async)
return 0;
@@ -125,7 +125,7 @@ int wfx_cmd_send(struct wfx_dev *wdev, struct hif_msg
*request,
// This function is special. After HIF_REQ_ID_SHUT_DOWN, chip won't reply to
any
// request anymore. We need to slightly hack struct wfx_hif_cmd for that job.
Be
-// carefull to only call this funcion during device unregister.
+// carefull to only call this function during device unregister.
int hif_shutdown(struct wfx_dev *wdev)
{
int ret;
diff --git a/drivers/staging/wfx/main.c b/drivers/staging/wfx/main.c
index 11dfa088fc86..4263f912760b 100644
--- a/drivers/staging/wfx/main.c
+++ b/drivers/staging/wfx/main.c
@@ -384,7 +384,7 @@ int wfx_probe(struct wfx_dev *wdev)
err = wfx_sl_init(wdev);
if (err && wdev->hw_caps.capabilities.link_mode == SEC_LINK_ENFORCED) {
dev_err(wdev->dev,
- "chip require
Re: issue with uninitialized value used in a comparison in gbcodec_mixer_dapm_ctl_put
On 7/30/20 11:02 AM, Colin Ian King wrote:
> Hi,
>
> Static analysis with Coverity has detected an uninitialized value being
> used in a comparison. The error was detected on a recent change to
> drivers/staging/greybus/audio_topology.c however the issue actually
> dates back to the original commit:
>
> commit 6339d2322c47f4b8ebabf9daf0130328ed72648b
> Author: Vaibhav Agarwal
> Date: Wed Jan 13 14:07:51 2016 -0700
>
> greybus: audio: Add topology parser for GB codec
>
> The analysis is as follows:
>
> 425 static int gbcodec_mixer_dapm_ctl_put(struct snd_kcontrol *kcontrol,
> 426 struct snd_ctl_elem_value
> *ucontrol)
> 427 {
> 428int ret, wi, max, connect;
> 429unsigned int mask, val;
> 430struct gb_audio_ctl_elem_info *info;
> 431struct gbaudio_ctl_pvt *data;
>
>1. var_decl: Declaring variable gbvalue without initializer.
> 432struct gb_audio_ctl_elem_value gbvalue;
> 433struct gbaudio_module_info *module;
> 434struct snd_soc_dapm_widget_list *wlist =
> snd_kcontrol_chip(kcontrol);
> 435struct snd_soc_dapm_widget *widget = wlist->widgets[0];
> 436struct device *codec_dev = widget->dapm->dev;
> 437struct gbaudio_codec_info *gb = dev_get_drvdata(codec_dev);
> 438struct gb_bundle *bundle;
> 439
>
>2. Condition 0 /* __builtin_types_compatible_p() */, taking false branch.
>3. Condition 1 /* __builtin_types_compatible_p() */, taking true branch.
>4. Falling through to end of if statement.
>5. Condition !!branch, taking false branch.
>6. Condition ({...; !!branch;}), taking false branch.
>
> 440dev_dbg(codec_dev, "Entered %s:%s\n", __func__,
> kcontrol->id.name);
> 441module = find_gb_module(gb, kcontrol->id.name);
>
>7. Condition !module, taking false branch.
> 442if (!module)
> 443return -EINVAL;
> 444
> 445data = (struct gbaudio_ctl_pvt *)kcontrol->private_value;
> 446info = (struct gb_audio_ctl_elem_info *)data->info;
>
>8. Condition 0 /* !!(!__builtin_types_compatible_p() &&
> !__builtin_types_compatible_p()) */, taking false branch.
> 447bundle = to_gb_bundle(module->dev);
> 448
>
>9. Condition data->vcount == 2, taking true branch.
> 449if (data->vcount == 2)
> 450dev_warn(widget->dapm->dev,
> 451 "GB: Control '%s' is stereo, which is not
> supported\n",
> 452 kcontrol->id.name);
> 453
> 454max = le32_to_cpu(info->value.integer.max);
> 455mask = (1 << fls(max)) - 1;
> 456val = ucontrol->value.integer.value[0] & mask;
>
>10. Condition !!val, taking true branch.
> 457connect = !!val;
> 458
> 459/* update ucontrol */
>
> Uninitialized scalar variable (UNINIT)
>11. uninit_use: Using uninitialized value gbvalue.value.integer_value[0].
> 460if (gbvalue.value.integer_value[0] != val) {
>
> The gbvalue.value.integer_value[0] read is bogus since gbvalue was
> declared on the stack but was not initialized. There seems to be no
> where that sets this data. I'm assuming most of the time that the
> comparison works because the garbage value is different from val and so
> the code in the if stanza is executed.
>
> Anyhow, I'm unsure what the original intent of the code was, so I've not
> attempted to fix this.
I think the fix is to add a call to this:
ret = gb_audio_gb_get_control(module->mgmt_connection, data->ctl_id,
GB_AUDIO_INVALID_INDEX, );
before the field within gbvalue is used.
Looking at gbcodec_mixer_dapm_ctl_get() defined just above that, it
seems that the call to gb_audio_gb_get_control() should be preceded
by a call to gb_pm_runtime_get_sync(). And given that duplication,
I suggest this call and the PM runtime wrapper functions should be
placed in a new helper function.
I know that Vaibhav said he would be fixing this, so I guess my
comments are directed at him. Thanks for sending the patch Colin.
-Alex
> Colin
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [greybus-dev] [PATCH v4 1/7] staging: greybus: audio: Update snd_jack FW usage as per new APIs
On 7/9/20 5:27 AM, Vaibhav Agarwal wrote:
> snd_soc_jack APIs are modified in recent kernel versions. This patch
> updates the codec driver to resolve the compilation errors related to
> jack framework.
Greg has already accepted this series so I won't review this now. But
I still wanted to provide this comment.
It would be helpful in the future to provide a little more information
about the nature of the changes to these APIs. As a reviewer I had to
go track them down to get a little more context about what you are doing
here. So you could say something like:
Audio jacks are now registered at the card level rather than being
associated with a CODEC. The new card-based API allows a jack's pins
to be supplied when the jack is first registered. See: 970939964c26
("ASoC: Allow to register jacks at the card level")
In other words, don't just say "the APIs changed," say "here is how
the APIs have changed." This kind of introduction can be very helpful
and time saving for your reviewers.
-Alex
> Signed-off-by: Vaibhav Agarwal
> Reviewed-by: Dan Carpenter
> ---
> drivers/staging/greybus/audio_codec.c | 54 +--
> 1 file changed, 42 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/staging/greybus/audio_codec.c
> b/drivers/staging/greybus/audio_codec.c
> index 08746c85dea6..5d3a5e6a8fe6 100644
> --- a/drivers/staging/greybus/audio_codec.c
> +++ b/drivers/staging/greybus/audio_codec.c
> @@ -709,17 +709,26 @@ static struct snd_soc_dai_driver gbaudio_dai[] = {
> };
>
> static int gbaudio_init_jack(struct gbaudio_module_info *module,
> - struct snd_soc_codec *codec)
> + struct snd_soc_card *card)
> {
> int ret;
> + struct snd_soc_jack_pin *headset, *button;
>
> if (!module->jack_mask)
> return 0;
>
> snprintf(module->jack_name, NAME_SIZE, "GB %d Headset Jack",
>module->dev_id);
> - ret = snd_soc_jack_new(codec, module->jack_name, module->jack_mask,
> ->headset_jack);
> +
> + headset = devm_kzalloc(module->dev, sizeof(*headset), GFP_KERNEL);
> + if (!headset)
> + return -ENOMEM;
> +
> + headset->pin = module->jack_name;
> + headset->mask = module->jack_mask;
> +
> + ret = snd_soc_card_jack_new(card, module->jack_name, module->jack_mask,
> + >headset_jack, headset, 1);
> if (ret) {
> dev_err(module->dev, "Failed to create new jack\n");
> return ret;
> @@ -730,11 +739,21 @@ static int gbaudio_init_jack(struct gbaudio_module_info
> *module,
>
> snprintf(module->button_name, NAME_SIZE, "GB %d Button Jack",
>module->dev_id);
> - ret = snd_soc_jack_new(codec, module->button_name, module->button_mask,
> ->button_jack);
> + button = devm_kzalloc(module->dev, sizeof(*button), GFP_KERNEL);
> + if (!button) {
> + ret = -ENOMEM;
> + goto free_headset;
> + }
> +
> + button->pin = module->button_name;
> + button->mask = module->button_mask;
> +
> + ret = snd_soc_card_jack_new(card, module->button_name,
> + module->button_mask, >button_jack,
> + button, 1);
> if (ret) {
> dev_err(module->dev, "Failed to create button jack\n");
> - return ret;
> + goto free_headset;
> }
>
> /*
> @@ -750,7 +769,7 @@ static int gbaudio_init_jack(struct gbaudio_module_info
> *module,
> KEY_MEDIA);
> if (ret) {
> dev_err(module->dev, "Failed to set BTN_0\n");
> - return ret;
> + goto free_button;
> }
> }
>
> @@ -759,7 +778,7 @@ static int gbaudio_init_jack(struct gbaudio_module_info
> *module,
> KEY_VOICECOMMAND);
> if (ret) {
> dev_err(module->dev, "Failed to set BTN_1\n");
> - return ret;
> + goto free_button;
> }
> }
>
> @@ -768,7 +787,7 @@ static int gbaudio_init_jack(struct gbaudio_module_info
> *module,
> KEY_VOLUMEUP);
> if (ret) {
> dev_err(module->dev, "Failed to set BTN_2\n");
> - return ret;
> + goto free_button;
> }
> }
>
> @@ -777,7 +796,7 @@ static int gbaudio_init_jack(struct gbaudio_module_info
> *module,
> KEY_VOLUMEDOWN);
> if (ret) {
> dev_err(module->dev, "Failed to set BTN_0\n");
> - return ret;
> + goto free_button;
> }
> }
>
> @@ -788,6 +807,16 @@
Re: [greybus-dev] [PATCH] staging: greybus: audio: Uninitialized variable in gbaudio_remove_controls()
On 8/4/20 5:16 AM, Dan Carpenter wrote:
> The "err" variable is not meaningful so there is no need to print it.
> It's uninitialized on the first iteration through the loop.
>
> Fixes: 510e340efe0c ("staging: greybus: audio: Add helper APIs for dynamic
> audio modules")
> Signed-off-by: Dan Carpenter
This is a good fix, thanks.
Reviewed-by: Alex Elder
> ---
> drivers/staging/greybus/audio_helper.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/staging/greybus/audio_helper.c
> b/drivers/staging/greybus/audio_helper.c
> index 8b100a71f02e..237531ba60f3 100644
> --- a/drivers/staging/greybus/audio_helper.c
> +++ b/drivers/staging/greybus/audio_helper.c
> @@ -173,8 +173,7 @@ static int gbaudio_remove_controls(struct snd_card *card,
> struct device *dev,
> id.index = control->index;
> kctl = snd_ctl_find_id(card, );
> if (!kctl) {
> - dev_err(dev, "%d: Failed to find %s\n", err,
> - control->name);
> + dev_err(dev, "Failed to find %s\n", control->name);
> continue;
> }
> err = snd_ctl_remove(card, kctl);
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] sched: Provide USF for the portable equipment.
On 08/05/20 19:13, Dongdong Yang wrote: > Appreciate Qais for your clamp implementation. I would like to add traces > for uclamp_rq_util_with and feedback you if I run into any issues. Thanks. FYI, top posting in LKML is frowned upon. Please put your answer underneath the quoted text. > > The util would not be adjusted as soon as FB screen on notification be > received by USF from kernel level if it is set by sched_usf_non_ux, no > matter whether screen on or off. However, sched_util_clamp_min/max have not > been recovered until user space screen on detection. The screen on response > would not be in time for the sensitive user when many background tasks are > running. Whether the kernel module could also > set sched_util_clamp_min/max? For boosting, are you just changing the sysctl or are you actively using sched_setattr() to boost tasks too? Please have a look at the documentation for the sysctl interface. https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/tree/Documentation/admin-guide/sysctl/kernel.rst?h=sched/core#n1065 In summary, they just control the _allowed_ levels. So you can use it to cap/throttle the maximum performance level the system is running at. But you can't use it to boost the whole system. You must use the sched_setattr() to boost important tasks individually or if all the tasks are in a cgroup you can use that. For cgroup interface there's a caveat. If you want to use it let me know so I can explain how boosting would work there. I advise to use the sched_setattr() interface to target and boost those important tasks only. You can as well be smart and target all the background tasks to cap them via sched_setattr(). In this case you wouldn't have to modify the sysctl_sched_util_clamp_min/max. I don't see uclamp being a suitable interface for in-kernel users. PM_QOS is more suitable in my opinion for in-kernel users if you want to impact the overall system performance. I might have misunderstood what you were saying above. If so, can you please rephrase? Thanks -- Qais Yousef ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: wfx: refactor to avoid duplication at hif_tx.c
Add functions wfx_full_send(), wfx_full_send_no_reply_async(),
wfx_full_send_no_reply() and wfx_full_send_no_reply_free()
which works as follow:
wfx_full_send() - simple wrapper for both wfx_fill_header()
and wfx_cmd_send().
wfx_full_send_no_reply_async() - wrapper for both but with
NULL as reply and size zero.
wfx_full_send_no_reply() - same as wfx_full_send_no_reply_async()
but with false async value
wfx_full_send_no_reply_free() - same as wfx_full_send_no_reply()
but also free the struct hif_msg.
Signed-off-by: Tomer Samara
---
Changes in v2:
- Changed these functions to static
drivers/staging/wfx/hif_tx.c | 180 ---
1 file changed, 80 insertions(+), 100 deletions(-)
diff --git a/drivers/staging/wfx/hif_tx.c b/drivers/staging/wfx/hif_tx.c
index 5110f9b93762..17f668fa40a0 100644
--- a/drivers/staging/wfx/hif_tx.c
+++ b/drivers/staging/wfx/hif_tx.c
@@ -40,7 +40,7 @@ static void wfx_fill_header(struct hif_msg *hif, int if_id,
static void *wfx_alloc_hif(size_t body_len, struct hif_msg **hif)
{
- *hif = kzalloc(sizeof(struct hif_msg) + body_len, GFP_KERNEL);
+ *hif = kzalloc(sizeof(*hif) + body_len, GFP_KERNEL);
if (*hif)
return (*hif)->body;
else
@@ -123,9 +123,39 @@ int wfx_cmd_send(struct wfx_dev *wdev, struct hif_msg
*request,
return ret;
}
+static int wfx_full_send(struct wfx_dev *wdev, struct hif_msg *hif, void
*reply,
+size_t reply_len, bool async, int if_id, unsigned int
cmd,
+int size)
+{
+ wfx_fill_header(hif, if_id, cmd, size);
+ return wfx_cmd_send(wdev, hif, reply, reply_len, async);
+}
+
+static int wfx_full_send_no_reply_async(struct wfx_dev *wdev, struct hif_msg
*hif, int if_id,
+ unsigned int cmd, int size, bool async)
+{
+ return wfx_full_send(wdev, hif, NULL, 0, async, if_id, cmd, size);
+}
+
+static int wfx_full_send_no_reply(struct wfx_dev *wdev, struct hif_msg *hif,
int if_id,
+ unsigned int cmd, int size)
+{
+ return wfx_full_send_no_reply_async(wdev, hif, if_id, cmd, size, false);
+}
+
+static int wfx_full_send_no_reply_free(struct wfx_dev *wdev, struct hif_msg
*hif, int if_id,
+ unsigned int cmd, int size)
+{
+ int ret;
+
+ ret = wfx_full_send_no_reply(wdev, hif, if_id, cmd, size);
+ kfree(hif);
+ return ret;
+}
+
// This function is special. After HIF_REQ_ID_SHUT_DOWN, chip won't reply to
any
// request anymore. We need to slightly hack struct wfx_hif_cmd for that job.
Be
-// carefull to only call this funcion during device unregister.
+// careful to only call this function during device unregister.
int hif_shutdown(struct wfx_dev *wdev)
{
int ret;
@@ -136,8 +166,8 @@ int hif_shutdown(struct wfx_dev *wdev)
wfx_alloc_hif(0, );
if (!hif)
return -ENOMEM;
- wfx_fill_header(hif, -1, HIF_REQ_ID_SHUT_DOWN, 0);
- ret = wfx_cmd_send(wdev, hif, NULL, 0, true);
+ ret = wfx_full_send_no_reply_async(wdev, hif, -1, HIF_REQ_ID_SHUT_DOWN,
+ 0, true);
// After this command, chip won't reply. Be sure to give enough time to
// bh to send buffer:
msleep(100);
@@ -154,7 +184,6 @@ int hif_shutdown(struct wfx_dev *wdev)
int hif_configuration(struct wfx_dev *wdev, const u8 *conf, size_t len)
{
- int ret;
size_t buf_len = sizeof(struct hif_req_configuration) + len;
struct hif_msg *hif;
struct hif_req_configuration *body = wfx_alloc_hif(buf_len, );
@@ -163,25 +192,20 @@ int hif_configuration(struct wfx_dev *wdev, const u8
*conf, size_t len)
return -ENOMEM;
body->length = cpu_to_le16(len);
memcpy(body->pds_data, conf, len);
- wfx_fill_header(hif, -1, HIF_REQ_ID_CONFIGURATION, buf_len);
- ret = wfx_cmd_send(wdev, hif, NULL, 0, false);
- kfree(hif);
- return ret;
+ return wfx_full_send_no_reply_free(wdev, hif, -1,
HIF_REQ_ID_CONFIGURATION,
+ buf_len);
}
int hif_reset(struct wfx_vif *wvif, bool reset_stat)
{
- int ret;
struct hif_msg *hif;
struct hif_req_reset *body = wfx_alloc_hif(sizeof(*body), );
if (!hif)
return -ENOMEM;
body->reset_flags.reset_stat = reset_stat;
- wfx_fill_header(hif, wvif->id, HIF_REQ_ID_RESET, sizeof(*body));
- ret = wfx_cmd_send(wvif->wdev, hif, NULL, 0, false);
- kfree(hif);
- return ret;
+ return wfx_full_send_no_reply_free(wvif->wdev, hif, wvif->id,
+ HIF_REQ_ID_RESET, sizeof(*body));
}
int hif_read_mib(struct wfx_dev *wdev, int vif_id, u16 mib_id,
@@ -198,9 +222,8 @@ int
Re: [PATCH v3] Provide USF for the portable equipment.
On Tue, Aug 04, 2020 at 11:17:28AM +0530, Viresh Kumar wrote: > Sending updated patchset for this isn't going to help you my friend. You need > people (maintainers) to agree on the idea here first. It doesn't take much work to make the code look nice. Writing pretty code is always a good idea because then people assume you know what you're doing. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: ion: fix spelling mistake in function name "detatch" -> "detach"
From: Colin Ian King
There is a spelling mistake in the function name ion_dma_buf_detatch.
Fix it by removing the extraneous t.
Signed-off-by: Colin Ian King
---
drivers/staging/android/ion/ion.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 3c9f09506ffa..e1fe03ceb7f1 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -205,8 +205,8 @@ static int ion_dma_buf_attach(struct dma_buf *dmabuf,
return 0;
}
-static void ion_dma_buf_detatch(struct dma_buf *dmabuf,
- struct dma_buf_attachment *attachment)
+static void ion_dma_buf_detach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
{
struct ion_dma_buf_attachment *a = attachment->priv;
struct ion_buffer *buffer = dmabuf->priv;
@@ -331,7 +331,7 @@ static const struct dma_buf_ops dma_buf_ops = {
.mmap = ion_mmap,
.release = ion_dma_buf_release,
.attach = ion_dma_buf_attach,
- .detach = ion_dma_buf_detatch,
+ .detach = ion_dma_buf_detach,
.begin_cpu_access = ion_dma_buf_begin_cpu_access,
.end_cpu_access = ion_dma_buf_end_cpu_access,
};
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wfx: refactor to avoid duplication at hif_tx.c
Hi Tomer,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on staging/staging-testing]
url:
https://github.com/0day-ci/linux/commits/Tomer-Samara/staging-wfx-refactor-to-avoid-duplication-at-hif_tx-c/20200805-165649
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
5bbd90550da8f7bdac769b5825597e67183c9411
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from arch/m68k/include/asm/io_mm.h:25,
from arch/m68k/include/asm/io.h:8,
from include/linux/scatterlist.h:9,
from include/linux/dma-mapping.h:11,
from include/linux/skbuff.h:31,
from include/linux/if_ether.h:19,
from include/linux/etherdevice.h:20,
from drivers/staging/wfx/hif_tx.c:9:
arch/m68k/include/asm/raw_io.h: In function 'raw_rom_outsb':
arch/m68k/include/asm/raw_io.h:83:7: warning: variable '__w' set but not
used [-Wunused-but-set-variable]
83 | ({u8 __w, __v = (b); u32 _addr = ((u32) (addr)); \
| ^~~
arch/m68k/include/asm/raw_io.h:430:3: note: in expansion of macro 'rom_out_8'
430 | rom_out_8(port, *buf++);
| ^
arch/m68k/include/asm/raw_io.h: In function 'raw_rom_outsw':
arch/m68k/include/asm/raw_io.h:86:8: warning: variable '__w' set but not
used [-Wunused-but-set-variable]
86 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); \
|^~~
arch/m68k/include/asm/raw_io.h:448:3: note: in expansion of macro
'rom_out_be16'
448 | rom_out_be16(port, *buf++);
| ^~~~
arch/m68k/include/asm/raw_io.h: In function 'raw_rom_outsw_swapw':
arch/m68k/include/asm/raw_io.h:90:8: warning: variable '__w' set but not
used [-Wunused-but-set-variable]
90 | ({u16 __w, __v = (w); u32 _addr = ((u32) (addr)); \
|^~~
arch/m68k/include/asm/raw_io.h:466:3: note: in expansion of macro
'rom_out_le16'
466 | rom_out_le16(port, *buf++);
| ^~~~
In file included from include/linux/kernel.h:11,
from include/linux/skbuff.h:13,
from include/linux/if_ether.h:19,
from include/linux/etherdevice.h:20,
from drivers/staging/wfx/hif_tx.c:9:
include/linux/scatterlist.h: In function 'sg_set_buf':
arch/m68k/include/asm/page_mm.h:169:49: warning: ordered comparison of
pointer with null pointer [-Wextra]
169 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void
*)PAGE_OFFSET && (void *)(kaddr) < high_memory)
| ^~
include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
78 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
include/linux/scatterlist.h:143:2: note: in expansion of macro 'BUG_ON'
143 | BUG_ON(!virt_addr_valid(buf));
| ^~
include/linux/scatterlist.h:143:10: note: in expansion of macro
'virt_addr_valid'
143 | BUG_ON(!virt_addr_valid(buf));
| ^~~
In file included from arch/m68k/include/asm/bug.h:32,
from include/linux/bug.h:5,
from include/linux/thread_info.h:12,
from include/asm-generic/preempt.h:5,
from ./arch/m68k/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/skbuff.h:15,
from include/linux/if_ether.h:19,
from include/linux/etherdevice.h:20,
from drivers/staging/wfx/hif_tx.c:9:
include/linux/dma-mapping.h: In function 'dma_map_resource':
arch/m68k/include/asm/page_mm.h:169:49: warning: ordered comparison of
pointer with null pointer [-Wextra]
169 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void
*)PAGE_OFFSET && (void *)(kaddr) < high_memory)
| ^~
include/asm-generic/bug.h:144:27: note: in definition of macro 'WARN_ON_ONCE'
144 | int __ret_warn_once = !!(condition); \
| ^
arch/m68k/
Re: [PATCH v5] sched: Provide USF for the portable equipment.
On Wed, Aug 05, 2020 at 03:36:21PM +0800, Dongdong Yang wrote: > From: Dongdong Yang > > The power consumption and UI response are more cared for by the portable > equipment users. USF(User Sensitive Feedback factor) auxiliary cpufreq > governor is providing more util adjustment settings to the high level > by scenario identification. > > From the view of portable equipment, screen off status usually stands > for no request from the user, however, the kernel is still expected to > notify the user in time on modem, network or powerkey events occur. In > some scenarios, such as listening to music, low power processors, such > as DSP, take more actions and CPU load requirements cut down. It would > bring more power consumption benefit if high level have interfaces to > adjust utils according to the current scenario and load. > > In addition, the portable equipment user usually heavily interact with > devices by touch, and other peripherals. The boost preemptive counts > are marking the load requirement urgent, vice versa. If such feedback > factor could be set to high level according to the scenario, it would > contribute to the power consumption and UI response. > > If no USF sysfs inode is set, and no screen on or off event, > adjust_pred_demand shall not be invoked. Once up_l0_r down_r or non_ux_r > be set, adjust_pred_demand shall be called back to update settings > according to high level scenario identification. > > We can get about 17% mean power consumption save at listening to music > with speaker on "screen off" scenario, as below statistical data from > 7766 XiaoMi devices for two weeks with non_ux_r be set: > > day1 day2 day3 day4 > count 7766.00 7766.00 7766.00 7766.00 > mean88.03552585.50028283.82930586.054997 > std 111.049980 108.258834 107.562583 108.558240 > min 0.099000 0.037000 0.067000 0.045000 > 25% 34.76550034.02175034.10150034.423000 > 50% 54.9555.28650054.18950054.248500 > 75% 95.95400093.94200091.73800094.0592500 > 80% 114.675000 107.43 106.378000 108.673000 > 85% 137.851000 129.511000 127.156500 131.750750 > 90% 179.669000 170.208500 164.027000 172.348000 > 95% 272.395000 257.845500 247.750500 263.275750 > 98% 399.034500 412.170400 391.484000 402.835600 > > day5 day6day7 day8 > count 7766.00 7766.0 7766.00 7766.00 > mean82.53267779.2192377.61138081.075081 > std 104.870079 101.34819 103.140037 97.506221 > min 0.051000 0.02900 0.007000 0.068000 > 25% 32.87300033.4440031.96550033.863500 > 50% 52.18050051.5655050.80650053.08 > 75% 90.90575086.8262583.85925089.973000 > 80% 105.455000 99.6470097.271000104.225000 > 85% 128.30 118.47825 116.570250 126.648250 > 90% 166.647500 149.18000 150.649500 161.087000 > 95% 247.208500 224.36050 226.38 245.291250 > 98% 393.002000 347.92060 369.791800 378.778600 > > day9 day10day11day12 > count 7766.00 7766.00 7766.00 7766.00 > mean79.98917083.85941778.03293077.060542 > std 104.226122 108.893043 102.561715 99.844276 > min 0.118000 0.017000 0.028000 0.039000 > 25% 32.05625033.45450031.17625030.897750 > 50% 51.50600054.05600048.96950049.069000 > 75% 88.51350092.95350083.50675084.096000 > 80% 102.876000 107.845000 97.71700098.073000 > 85% 124.363000 128.288000 118.366500 116.869250 > 90% 160.557000 167.084000 154.342500 148.187500 > 95% 231.149000 242.925750 236.759000 228.131250 > 98% 367.206600 388.619100 385.269100 376.541600 > > day13day14 > count 7766.00 7766.00 > mean75.52803673.702878 > std 90.75059486.796016 > min 0.066000 0.054000 > 25% 31.17050031.608500 > 50% 48.75850049.215000 > 75% 84.52275083.053000 > 80% 97.87900094.875000 > 85% 116.680250 113.573750 > 90% 149.083500 144.089500 > 95% 226.177750 211.488750 > 98% 347.011100 331.317100 > > Signed-off-by: Dongdong Yang > Co-developed-by: Jun Tao > Co-developed-by: Qiwu Huang > Co-developed-by: Peng Wang > Signed-off-by: Dongdong Yang > --- > Documentation/ABI/testing/sysfs-devices-system-cpu | 31 ++ > drivers/cpufreq/Kconfig| 11 + > kernel/sched/Makefile | 1 + > kernel/sched/cpufreq_schedutil.c | 5 + > kernel/sched/usf.c | 314 > + > 5 files changed, 362 insertions(+) > create mode 100644 kernel/sched/usf.c > > diff --git
Re: [PATCH] staging: wfx: refactor to avoid duplication at hif_tx.c
On Wed, Aug 05, 2020 at 11:04:25AM +0200, Greg KH wrote: > On Wed, Aug 05, 2020 at 11:56:08AM +0300, Tomer Samara wrote: > > Add functions wfx_full_send(), wfx_full_send_no_reply_async(), > > wfx_full_send_no_reply() and wfx_full_send_no_reply_free() > > which works as follow: > > wfx_full_send() - simple wrapper for both wfx_fill_header() > > and wfx_cmd_send(). > > wfx_full_send_no_reply_async() - wrapper for both but with > > NULL as reply and size zero. > > wfx_full_send_no_reply() - same as wfx_full_send_no_reply_async() > >but with false async value > > wfx_full_send_no_reply_free() - same as wfx_full_send_no_reply() > > but also free the struct hif_msg. > > Please only do one-thing-per-patch. Why shouldn't this be a 4 patch > series? > > thanks, > > greg k-h All of the 4 functions are wrappers for the same duplicate code when every time there are different flags, so they are all connected, it is feel to me more legit to patch them all together, should I split them into 4 different patches? Thanks, Tomer Samara ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] sched: Provide USF for the portable equipment.
On 08/05/20 03:33, Dongdong Yang wrote: > Appreciate Qais for your above comments. I believe the clamp is very good for > terminal devices per pid or cgroup setting. I really hope it works for the > extended scenario, "screen off", although it has a potential side effect on > "screen on" response because it needs to be recovered at high level with > latency. I set "512" to sched_util_clamp_min and max on screen off for our > developing device with android kernel5.4. However, it still could not > replace sched_usf_non_ux_r from the test result as attachment. The cpufreq > could not go down in time. > Screenshot at 2020-08-05 09:56:38.png Please fix your email client so that it doesn't send in HTML. LKML will reject HTML emails. I can't interpret the numbers in the pictures. Can you help explain what am I looking at? I did see an issue with frequency not capped immediately when the system was busy. I am still trying to debug that. I already fixed one problem related to iowait boost not honouring uclamp requests, I will be posting a patch for this soon. If you have IO heavy workload, then iowait boost will cause schedutil to run at high frequency, and uclamp capping is not applied in that path. Can you trace what happens inside uclamp_rq_util_with() when it's called from sched_cpu_util()? The clamp should be applied quickly, so it's a bug we need to fix. In my case I noticed if I ctrl+Z then `fg`, the cap is applied. My hands are full to look at this soon. So if you can trace it, that'd be great. Can you expand more on your worry for "screen on"? The only latency I see is userspace not being able to set uclamp values quickly. But since it seems you already can set sched_usf_non_ux_r from userspace with acceptable results, then uclamp should be able to cover the same functionality. What am I missing? Thanks -- Qais Yousef ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wfx: refactor to avoid duplication at hif_tx.c
On Wed, Aug 05, 2020 at 11:56:08AM +0300, Tomer Samara wrote: > Add functions wfx_full_send(), wfx_full_send_no_reply_async(), > wfx_full_send_no_reply() and wfx_full_send_no_reply_free() > which works as follow: > wfx_full_send() - simple wrapper for both wfx_fill_header() > and wfx_cmd_send(). > wfx_full_send_no_reply_async() - wrapper for both but with > NULL as reply and size zero. > wfx_full_send_no_reply() - same as wfx_full_send_no_reply_async() >but with false async value > wfx_full_send_no_reply_free() - same as wfx_full_send_no_reply() > but also free the struct hif_msg. Please only do one-thing-per-patch. Why shouldn't this be a 4 patch series? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wfx: refactor to avoid duplication at hif_tx.c
Add functions wfx_full_send(), wfx_full_send_no_reply_async(),
wfx_full_send_no_reply() and wfx_full_send_no_reply_free()
which works as follow:
wfx_full_send() - simple wrapper for both wfx_fill_header()
and wfx_cmd_send().
wfx_full_send_no_reply_async() - wrapper for both but with
NULL as reply and size zero.
wfx_full_send_no_reply() - same as wfx_full_send_no_reply_async()
but with false async value
wfx_full_send_no_reply_free() - same as wfx_full_send_no_reply()
but also free the struct hif_msg.
Signed-off-by: Tomer Samara
---
drivers/staging/wfx/hif_tx.c | 179 ---
1 file changed, 79 insertions(+), 100 deletions(-)
diff --git a/drivers/staging/wfx/hif_tx.c b/drivers/staging/wfx/hif_tx.c
index 5110f9b93762..1ee84e5d47ef 100644
--- a/drivers/staging/wfx/hif_tx.c
+++ b/drivers/staging/wfx/hif_tx.c
@@ -40,7 +40,7 @@ static void wfx_fill_header(struct hif_msg *hif, int if_id,
static void *wfx_alloc_hif(size_t body_len, struct hif_msg **hif)
{
- *hif = kzalloc(sizeof(struct hif_msg) + body_len, GFP_KERNEL);
+ *hif = kzalloc(sizeof(*hif) + body_len, GFP_KERNEL);
if (*hif)
return (*hif)->body;
else
@@ -123,9 +123,38 @@ int wfx_cmd_send(struct wfx_dev *wdev, struct hif_msg
*request,
return ret;
}
+int wfx_full_send(struct wfx_dev *wdev, struct hif_msg *hif, void *reply,
size_t reply_len,
+ bool async, int if_id, unsigned int cmd, int size)
+{
+ wfx_fill_header(hif, if_id, cmd, size);
+ return wfx_cmd_send(wdev, hif, reply, reply_len, async);
+}
+
+int wfx_full_send_no_reply_async(struct wfx_dev *wdev, struct hif_msg *hif,
int if_id,
+unsigned int cmd, int size, bool async)
+{
+ return wfx_full_send(wdev, hif, NULL, 0, async, if_id, cmd, size);
+}
+
+int wfx_full_send_no_reply(struct wfx_dev *wdev, struct hif_msg *hif, int
if_id,
+ unsigned int cmd, int size)
+{
+ return wfx_full_send_no_reply_async(wdev, hif, if_id, cmd, size, false);
+}
+
+int wfx_full_send_no_reply_free(struct wfx_dev *wdev, struct hif_msg *hif, int
if_id,
+ unsigned int cmd, int size)
+{
+ int ret;
+
+ ret = wfx_full_send_no_reply(wdev, hif, if_id, cmd, size);
+ kfree(hif);
+ return ret;
+}
+
// This function is special. After HIF_REQ_ID_SHUT_DOWN, chip won't reply to
any
// request anymore. We need to slightly hack struct wfx_hif_cmd for that job.
Be
-// carefull to only call this funcion during device unregister.
+// careful to only call this function during device unregister.
int hif_shutdown(struct wfx_dev *wdev)
{
int ret;
@@ -136,8 +165,8 @@ int hif_shutdown(struct wfx_dev *wdev)
wfx_alloc_hif(0, );
if (!hif)
return -ENOMEM;
- wfx_fill_header(hif, -1, HIF_REQ_ID_SHUT_DOWN, 0);
- ret = wfx_cmd_send(wdev, hif, NULL, 0, true);
+ ret = wfx_full_send_no_reply_async(wdev, hif, -1, HIF_REQ_ID_SHUT_DOWN,
+ 0, true);
// After this command, chip won't reply. Be sure to give enough time to
// bh to send buffer:
msleep(100);
@@ -154,7 +183,6 @@ int hif_shutdown(struct wfx_dev *wdev)
int hif_configuration(struct wfx_dev *wdev, const u8 *conf, size_t len)
{
- int ret;
size_t buf_len = sizeof(struct hif_req_configuration) + len;
struct hif_msg *hif;
struct hif_req_configuration *body = wfx_alloc_hif(buf_len, );
@@ -163,25 +191,20 @@ int hif_configuration(struct wfx_dev *wdev, const u8
*conf, size_t len)
return -ENOMEM;
body->length = cpu_to_le16(len);
memcpy(body->pds_data, conf, len);
- wfx_fill_header(hif, -1, HIF_REQ_ID_CONFIGURATION, buf_len);
- ret = wfx_cmd_send(wdev, hif, NULL, 0, false);
- kfree(hif);
- return ret;
+ return wfx_full_send_no_reply_free(wdev, hif, -1,
HIF_REQ_ID_CONFIGURATION,
+ buf_len);
}
int hif_reset(struct wfx_vif *wvif, bool reset_stat)
{
- int ret;
struct hif_msg *hif;
struct hif_req_reset *body = wfx_alloc_hif(sizeof(*body), );
if (!hif)
return -ENOMEM;
body->reset_flags.reset_stat = reset_stat;
- wfx_fill_header(hif, wvif->id, HIF_REQ_ID_RESET, sizeof(*body));
- ret = wfx_cmd_send(wvif->wdev, hif, NULL, 0, false);
- kfree(hif);
- return ret;
+ return wfx_full_send_no_reply_free(wvif->wdev, hif, wvif->id,
+ HIF_REQ_ID_RESET, sizeof(*body));
}
int hif_read_mib(struct wfx_dev *wdev, int vif_id, u16 mib_id,
@@ -198,9 +221,8 @@ int hif_read_mib(struct wfx_dev *wdev, int vif_id, u16
mib_id,
goto out;
}
body->mib_id = cpu_to_le16(mib_id);
-
Re: [PATCH] staging: android: ashmem: used const keyword
Hi Dhiraj,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on staging/staging-testing]
url:
https://github.com/0day-ci/linux/commits/Dhiraj-Sharma/staging-android-ashmem-used-const-keyword/20200729-020222
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
11536442a3b4e1de6890ea5e805908debb74f94a
:: branch date: 6 days ago
:: commit date: 6 days ago
config: i386-randconfig-s002-20200803 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-117-g8c7aee71-dirty
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/staging/android/ashmem.c:418:25: sparse: sparse: assignment to const
>> expression
drivers/staging/android/ashmem.c:419:36: sparse: sparse: assignment to const
expression
drivers/staging/android/ashmem.c:420:36: sparse: sparse: assignment to const
expression
#
https://github.com/0day-ci/linux/commit/e200c35fc32789d0eec4878160474e62f9eebeb7
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout e200c35fc32789d0eec4878160474e62f9eebeb7
vim +418 drivers/staging/android/ashmem.c
6d67b0290b4b84 Suren Baghdasaryan 2020-01-27 367
11980c2ac4ccfa Robert Love2011-12-20 368 static int
ashmem_mmap(struct file *file, struct vm_area_struct *vma)
11980c2ac4ccfa Robert Love2011-12-20 369 {
e200c35fc32789 Dhiraj Sharma 2020-07-28 370 static const struct
file_operations vmfile_fops;
11980c2ac4ccfa Robert Love2011-12-20 371 struct ashmem_area
*asma = file->private_data;
11980c2ac4ccfa Robert Love2011-12-20 372 int ret = 0;
11980c2ac4ccfa Robert Love2011-12-20 373
11980c2ac4ccfa Robert Love2011-12-20 374
mutex_lock(_mutex);
11980c2ac4ccfa Robert Love2011-12-20 375
11980c2ac4ccfa Robert Love2011-12-20 376 /* user needs to
SET_SIZE before mapping */
59848d6aded59a Alistair Strachan 2018-06-19 377 if (!asma->size) {
11980c2ac4ccfa Robert Love2011-12-20 378 ret = -EINVAL;
11980c2ac4ccfa Robert Love2011-12-20 379 goto out;
11980c2ac4ccfa Robert Love2011-12-20 380 }
11980c2ac4ccfa Robert Love2011-12-20 381
8632c614565d0c Alistair Strachan 2018-06-19 382 /* requested mapping
size larger than object size */
8632c614565d0c Alistair Strachan 2018-06-19 383 if (vma->vm_end -
vma->vm_start > PAGE_ALIGN(asma->size)) {
11980c2ac4ccfa Robert Love2011-12-20 384 ret = -EINVAL;
11980c2ac4ccfa Robert Love2011-12-20 385 goto out;
11980c2ac4ccfa Robert Love2011-12-20 386 }
11980c2ac4ccfa Robert Love2011-12-20 387
11980c2ac4ccfa Robert Love2011-12-20 388 /* requested protection
bits must match our allowed protection mask */
59848d6aded59a Alistair Strachan 2018-06-19 389 if ((vma->vm_flags &
~calc_vm_prot_bits(asma->prot_mask, 0)) &
59848d6aded59a Alistair Strachan 2018-06-19 390
calc_vm_prot_bits(PROT_MASK, 0)) {
11980c2ac4ccfa Robert Love2011-12-20 391 ret = -EPERM;
11980c2ac4ccfa Robert Love2011-12-20 392 goto out;
11980c2ac4ccfa Robert Love2011-12-20 393 }
56f76fc68492af Arve Hjønnevåg 2011-12-20 394 vma->vm_flags &=
~calc_vm_may_flags(~asma->prot_mask);
11980c2ac4ccfa Robert Love2011-12-20 395
11980c2ac4ccfa Robert Love2011-12-20 396 if (!asma->file) {
11980c2ac4ccfa Robert Love2011-12-20 397 char *name =
ASHMEM_NAME_DEF;
11980c2ac4ccfa Robert Love2011-12-20 398 struct file
*vmfile;
11980c2ac4ccfa Robert Love2011-12-20 399
11980c2ac4ccfa Robert Love2011-12-20 400 if
(asma->name[ASHMEM_NAME_PREFIX_LEN] != '\0')
11980c2ac4ccfa Robert Love2011-12-20 401 name =
asma->name;
11980c2ac4ccfa Robert Love2011-12-20 402
11980c2ac4ccfa Robert Love2011-12-20 403 /* ... and
allocate the backing shmem file */
11980c2ac4ccfa Robert Love2011-12-20 404 vmfile =
shmem_file_setup(name, asma->size, vma->vm_flags);
7f44cb0ba88b40 Viresh Kumar 2015-07-31 405 if
(IS_ERR(vmfile)) {
11980c2ac4ccfa Robert Love2011-12-20 406 ret =
PTR_ERR(vmfile);
11980c2ac4ccfa Robert Love2011-12-20 407 goto
out;
11980c2ac4ccfa Robert Love2011-12-20 408 }
97fbfef6bd5978 Shuxiao Zhang 2017-04-06 409 vmfile->f_mode
|=
Re: [PATCH v5] sched: Provide USF for the portable equipment.
On Wed, Aug 05, 2020 at 03:36:21PM +0800, Dongdong Yang wrote: > +config SCHED_USF > + bool "User Sensitive Factors for Scheduler" > + depends on CPU_FREQ_GOV_SCHEDUTIL && FB > + help > + Select this option to enable the adjustment on the cpufreq with > + the user sensitive factors on schedule. It is special for mobile > + devices which more power care and quick response requirement on > + screen on. > + > + If unsure, say N. You're still suffering all the same problems, still NAK. Read carefully: "we do *NOT* do special case hacks" If you keep sending the same stuff over and over, you'll be elegible for an entry in my mailfilter. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5] sched: Provide USF for the portable equipment.
On Wed, Aug 05, 2020 at 03:36:21PM +0800, Dongdong Yang wrote: > +#define usf_attr_rw(_name) \ > +static struct device_attribute _name = > \ > +__ATTR_RW(_name) I also asked you to use DEVICE_ATTR_RW() and not use "raw" kobjects. Why you ignore code review is odd... greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5] sched: Provide USF for the portable equipment.
On Wed, Aug 05, 2020 at 03:36:21PM +0800, Dongdong Yang wrote: > --- /dev/null > +++ b/kernel/sched/usf.c > @@ -0,0 +1,314 @@ > +/* > + * Copyright (C) 2020 XiaoMi Inc. > + * Author: Yang Dongdong > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > + * See http://www.gnu.org/licenses/gpl-2.0.html for more details. > + */ You did not run checkpatch.pl on this patch, nor listen to my request to drop the boilerplate license text and just use a SPDX line :( greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v5] sched: Provide USF for the portable equipment.
From: Dongdong Yang The power consumption and UI response are more cared for by the portable equipment users. USF(User Sensitive Feedback factor) auxiliary cpufreq governor is providing more util adjustment settings to the high level by scenario identification. From the view of portable equipment, screen off status usually stands for no request from the user, however, the kernel is still expected to notify the user in time on modem, network or powerkey events occur. In some scenarios, such as listening to music, low power processors, such as DSP, take more actions and CPU load requirements cut down. It would bring more power consumption benefit if high level have interfaces to adjust utils according to the current scenario and load. In addition, the portable equipment user usually heavily interact with devices by touch, and other peripherals. The boost preemptive counts are marking the load requirement urgent, vice versa. If such feedback factor could be set to high level according to the scenario, it would contribute to the power consumption and UI response. If no USF sysfs inode is set, and no screen on or off event, adjust_pred_demand shall not be invoked. Once up_l0_r down_r or non_ux_r be set, adjust_pred_demand shall be called back to update settings according to high level scenario identification. We can get about 17% mean power consumption save at listening to music with speaker on "screen off" scenario, as below statistical data from 7766 XiaoMi devices for two weeks with non_ux_r be set: day1 day2 day3 day4 count 7766.00 7766.00 7766.00 7766.00 mean88.03552585.50028283.82930586.054997 std 111.049980 108.258834 107.562583 108.558240 min 0.099000 0.037000 0.067000 0.045000 25% 34.76550034.02175034.10150034.423000 50% 54.9555.28650054.18950054.248500 75% 95.95400093.94200091.73800094.0592500 80% 114.675000 107.43 106.378000 108.673000 85% 137.851000 129.511000 127.156500 131.750750 90% 179.669000 170.208500 164.027000 172.348000 95% 272.395000 257.845500 247.750500 263.275750 98% 399.034500 412.170400 391.484000 402.835600 day5 day6day7 day8 count 7766.00 7766.0 7766.00 7766.00 mean82.53267779.2192377.61138081.075081 std 104.870079 101.34819 103.140037 97.506221 min 0.051000 0.02900 0.007000 0.068000 25% 32.87300033.4440031.96550033.863500 50% 52.18050051.5655050.80650053.08 75% 90.90575086.8262583.85925089.973000 80% 105.455000 99.6470097.271000104.225000 85% 128.30 118.47825 116.570250 126.648250 90% 166.647500 149.18000 150.649500 161.087000 95% 247.208500 224.36050 226.38 245.291250 98% 393.002000 347.92060 369.791800 378.778600 day9 day10day11day12 count 7766.00 7766.00 7766.00 7766.00 mean79.98917083.85941778.03293077.060542 std 104.226122 108.893043 102.561715 99.844276 min 0.118000 0.017000 0.028000 0.039000 25% 32.05625033.45450031.17625030.897750 50% 51.50600054.05600048.96950049.069000 75% 88.51350092.95350083.50675084.096000 80% 102.876000 107.845000 97.71700098.073000 85% 124.363000 128.288000 118.366500 116.869250 90% 160.557000 167.084000 154.342500 148.187500 95% 231.149000 242.925750 236.759000 228.131250 98% 367.206600 388.619100 385.269100 376.541600 day13day14 count 7766.00 7766.00 mean75.52803673.702878 std 90.75059486.796016 min 0.066000 0.054000 25% 31.17050031.608500 50% 48.75850049.215000 75% 84.52275083.053000 80% 97.87900094.875000 85% 116.680250 113.573750 90% 149.083500 144.089500 95% 226.177750 211.488750 98% 347.011100 331.317100 Signed-off-by: Dongdong Yang Co-developed-by: Jun Tao Co-developed-by: Qiwu Huang Co-developed-by: Peng Wang Signed-off-by: Dongdong Yang --- Documentation/ABI/testing/sysfs-devices-system-cpu | 31 ++ drivers/cpufreq/Kconfig| 11 + kernel/sched/Makefile | 1 + kernel/sched/cpufreq_schedutil.c | 5 + kernel/sched/usf.c | 314 + 5 files changed, 362 insertions(+) create mode 100644 kernel/sched/usf.c diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index b555df8..e9a4cfd 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -614,3 +614,34 @@ Description:
[PATCH v5] Provide USF for the portable equipment.
From: Dongdong Yang This patch provides USF(User Sensitive Feedback factor) auxiliary cpufreq governor to support high level layer sysfs inodes setting for util adjustment purpose from the identified scenario on portable equipment. Because the power consumption and UI response are more cared for by portable equipment users. And the "screen off" status stands for no request from the user, however, the kernel is still expected to notify the user in time on modem, network or powerkey events occur. USF provides "non_ux_r" sysfs inode to cut down the utils from user space tasks according to high level scenario. In addition, it usually hints more cpufreq demand that the preemptive counts of the tasks on the cpu burst and over the user expecting completed time such as the ratio sysctl_sched_latency to sysctl_sched_min_granularity on "screen on" status, which more likely with more UI. The sysfs inodes "up_l0_r" and "down_r" have been provided to adjust the utils according to high level identified scenario to alloc the cpufreq in time. Changes in v5 Based on comments from Greg, Peterz, Qais and Randy - Updated USF sysfs to ABI - Updated the names of USF functions. - Clean sched.h and trace.h changes. Changes in v4 Based on comments from Greg, Randy and Viresh - Add USF sysfs to ABI - Remove kobj field from usf. - Clean Kconfig left at staging. Changes in v3 Based on comments from Greg, Dietmar, Christoph and Randy - Move usf.c to kernel/sched from staging. - Remove trace_printk and debugfs. - Add document draft. - Update comments. Changes in v2 Based on comments from Steven, Greg, Peter and Dan: - Add adjust_task_pred_set switch. - Move adjust_task_pred_demand declaration into sched.h - Update comments. - Clean usf structure. Changes in v1 Initial USF Dongdong Yang (1): sched: Provide USF for the portable equipment. Documentation/ABI/testing/sysfs-devices-system-cpu | 31 ++ drivers/cpufreq/Kconfig| 11 + kernel/sched/Makefile | 1 + kernel/sched/cpufreq_schedutil.c | 5 + kernel/sched/usf.c | 314 + 5 files changed, 362 insertions(+) create mode 100644 kernel/sched/usf.c -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
