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 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
Re: [PATCH v2] staging: wfx: fixed misspelled word in comment
From: Aditya Bansal
Subject: [PATCH v2] fixed typo in driver/staging/wfx/hif_tx.c file
Correct the spelling of word function and careful
Signed-off-by: Aditya Bansal
---
diff --git a/drivers/staging/wfx/hif_tx.c b/drivers/staging/wfx/hif_tx.c
index 5110f9b93762..fc12f9dcefce 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.
+// careful to only call this function during device unregister.
int hif_shutdown(struct wfx_dev *wdev)
{
int ret;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: greybus: audio: Uninitialized variable in gbaudio_remove_controls()
On Tue, Aug 4, 2020 at 3:46 PM 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
Thanks Dan for sharing this patch.
Reviewed-by: Vaibhav Agarwal
> ---
> 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);
> --
> 2.27.0
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wfx: fixed misspelled word in comment
On Tue, 2020-08-04 at 16:07 +0530, Aditya Bansal wrote: > Should I correct all the instances of the "careful" and submit the > patch including both "carefull" and "function" word correct? or only > for the "carefull"? I have already submitted one for the "funcion" > word. I suggest submitting a V2 patch with both fixes. Generally it's better to submit all spelling fixes in a single file at once, especially when multiple spelling fixes are on the same line. Also, it's generally better to submit separate patches for individual files. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wfx: fixed misspelled word in comment
Should I correct all the instances of the "careful" and submit the patch including both "carefull" and "function" word correct? or only for the "carefull"? I have already submitted one for the "funcion" word. On Tue, Aug 4, 2020 at 9:13 PM Joe Perches wrote: > > On Tue, 2020-08-04 at 08:24 -0700, Randy Dunlap wrote: > > On 8/4/20 7:58 AM, Aditya Bansal wrote: > > > From: Aditya Bansal > > > > > > Subject: [PATCH] fixed typo in driver/staging/wfx/hif_tx.c file > > > > > > Correct the spelling of function > > > > > > Signed-off-by: Aditya Bansal > > > --- > > > > > > diff --git a/drivers/staging/wfx/hif_tx.c b/drivers/staging/wfx/hif_tx.c > > > index 5110f9b93762..6a485fa5b72b 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 > > And if you could do all of them: > > $ git grep -w -i -n carefull > arch/m68k/coldfire/pci.c:34: * We need to be carefull probing on bus 0 > (directly connected to host > arch/openrisc/kernel/head.S:289: * a bit more carefull (if we have a > PT_SP or current pointer > drivers/staging/wfx/debug.c:302:// Be carefull, write() is waiting > for a full message while read() > drivers/staging/wfx/hif_tx.c:128:// carefull to only call this funcion during > device unregister. > fs/ceph/inode.c:1475: /* parent inode is not locked, be carefull */ > > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wfx: fixed misspelled word in comment
On Tue, 2020-08-04 at 08:24 -0700, Randy Dunlap wrote: > On 8/4/20 7:58 AM, Aditya Bansal wrote: > > From: Aditya Bansal > > > > Subject: [PATCH] fixed typo in driver/staging/wfx/hif_tx.c file > > > > Correct the spelling of function > > > > Signed-off-by: Aditya Bansal > > --- > > > > diff --git a/drivers/staging/wfx/hif_tx.c b/drivers/staging/wfx/hif_tx.c > > index 5110f9b93762..6a485fa5b72b 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 And if you could do all of them: $ git grep -w -i -n carefull arch/m68k/coldfire/pci.c:34: * We need to be carefull probing on bus 0 (directly connected to host arch/openrisc/kernel/head.S:289: * a bit more carefull (if we have a PT_SP or current pointer drivers/staging/wfx/debug.c:302:// Be carefull, write() is waiting for a full message while read() drivers/staging/wfx/hif_tx.c:128:// carefull to only call this funcion during device unregister. fs/ceph/inode.c:1475: /* parent inode is not locked, be carefull */ ___ 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 8/4/20 12:50 AM, Dongdong Yang wrote: > From: Dongdong Yang > > --- > > diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu > b/Documentation/ABI/testing/sysfs-devices-system-cpu > index b555df8..e299418 100644 > --- a/Documentation/ABI/testing/sysfs-devices-system-cpu > +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu > @@ -614,3 +614,51 @@ Description: SPURR ticks for cpuX when it was idle. > > This sysfs interface exposes the number of SPURR ticks > for cpuX when it was idle. > + > +What:/sys/devices/system/cpu/sched_usf > + /sys/devices/system/cpu/sched_usf/sched_usf_non_ux_r > + /sys/devices/system/cpu/sched_usf/sched_usf_up_l0_r > + /sys/devices/system/cpu/sched_usf/sched_usf_down_r > +Date:Aug 2020 > +Contact: Linux kernel mailing list > +Description: User Sensitive Feedback factor auxiliary scheduling which > + is providing more utils adjustment settings to the high level > + by scenario identification. what is "utils"? > + sched_usf_non_ux_r: > + The ratio of utils is cut down on screen off. The same question. > + default value is 0, which no util is adjusted on sugov what is "sugov"? > + calculating utils to select cpufreq. Its range is > + [-100 , 0]. If its value falls into [-50, 0), the half > + of utils, which calculates cpufreq, shall be cut down. > + If its value falls into [-100, -50), only a quarter of > + utils are left to continue to calculate cpufreq. > + It is expected to be set [-100, 0) once enter into the > + identificated scenario, such as listen to music on ^ not a word. > + screen off, and recover to 0 on out of the scenario, > + such as screen on. > + > + sched_usf_up_l0_r: > + The ratio of utils is boost up on screen on. The > + default value is 0, which no util is adjusted on sugov > + calculates utils to select cpufreq. Its range is [0 , > 100]. > + If its value falls into (0, 50], a quarter of extra > utils, > + which calculate cpufreq, shall be added. If its value > + falls into (50, 100], the half of extra utils are added > + to continue to calculate cpufreq. > + It is expected to be set (0, 100] once enter into the > + identificated scenario, such as browsing videolet on what is "videolet"? > + screen on, and recover to 0 on out of the scenario, > + such as screen off or videolet into background. > + > + sched_usf_down_r: > + The ratio of utils is cut down on screen on. The > + default value is 0, which no util is adjusted on sugov > + calculating utils to select cpufreq. Its range is > + [-100 , 0]. If its value falls into [-50, 0), the half > + of utils, which calculate cpufreq, shall be cut down. > + If its value falls into [-100, -50), only a quarter of > + utils are left to continue to calculate cpufreq. > + It is expected to be set [-100, 0) once enter into the > + identificated scenario, such as browsing videolet on > + screen on, and recover to 0 on out of the scenario, > + such as screen off or vidolet into background. -- ~Randy ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wfx: fixed misspelled word in comment
On 8/4/20 7:58 AM, Aditya Bansal wrote:
> From: Aditya Bansal
>
> Subject: [PATCH] fixed typo in driver/staging/wfx/hif_tx.c file
>
> Correct the spelling of function
>
> Signed-off-by: Aditya Bansal
> ---
>
> diff --git a/drivers/staging/wfx/hif_tx.c b/drivers/staging/wfx/hif_tx.c
> index 5110f9b93762..6a485fa5b72b 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;
--
~Randy
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wfx: fixed misspelled word in comment
From: Aditya Bansal
Subject: [PATCH] fixed typo in driver/staging/wfx/hif_tx.c file
Correct the spelling of function
Signed-off-by: Aditya Bansal
---
diff --git a/drivers/staging/wfx/hif_tx.c b/drivers/staging/wfx/hif_tx.c
index 5110f9b93762..6a485fa5b72b 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.
int hif_shutdown(struct wfx_dev *wdev)
{
int ret;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wlan-ng: fix out of bounds read in prism2sta_probe_usb()
let's use usb_find_common_endpoints() to discover endpoints, it does all
necessary checks for type and xfer direction
remove memset() in hfa384x_create(), because we now assign endpoints in
prism2sta_probe_usb() and because create_wlan() uses kzalloc() to
allocate hfa384x struct before calling hfa384x_create()
Fixes: faaff9765664 ("staging: wlan-ng: properly check endpoint types")
Reported-and-tested-by: syzbot+22794221ab96b0bab...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=22794221ab96b0bab53a
Signed-off-by: Rustam Kovhaev
---
drivers/staging/wlan-ng/hfa384x_usb.c | 5 -
drivers/staging/wlan-ng/prism2usb.c | 19 ++-
2 files changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index fa1bf8b069fd..2720f7319a3d 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -524,13 +524,8 @@ static void hfa384x_usb_defer(struct work_struct *data)
*/
void hfa384x_create(struct hfa384x *hw, struct usb_device *usb)
{
- memset(hw, 0, sizeof(*hw));
hw->usb = usb;
- /* set up the endpoints */
- hw->endp_in = usb_rcvbulkpipe(usb, 1);
- hw->endp_out = usb_sndbulkpipe(usb, 2);
-
/* Set up the waitq */
init_waitqueue_head(>cmdq);
diff --git a/drivers/staging/wlan-ng/prism2usb.c
b/drivers/staging/wlan-ng/prism2usb.c
index 456603fd26c0..4b08dc1da4f9 100644
--- a/drivers/staging/wlan-ng/prism2usb.c
+++ b/drivers/staging/wlan-ng/prism2usb.c
@@ -61,23 +61,14 @@ static int prism2sta_probe_usb(struct usb_interface
*interface,
const struct usb_device_id *id)
{
struct usb_device *dev;
- const struct usb_endpoint_descriptor *epd;
- const struct usb_host_interface *iface_desc = interface->cur_altsetting;
+ struct usb_endpoint_descriptor *bulk_in, *bulk_out;
+ struct usb_host_interface *iface_desc = interface->cur_altsetting;
struct wlandevice *wlandev = NULL;
struct hfa384x *hw = NULL;
int result = 0;
- if (iface_desc->desc.bNumEndpoints != 2) {
- result = -ENODEV;
- goto failed;
- }
-
- result = -EINVAL;
- epd = _desc->endpoint[1].desc;
- if (!usb_endpoint_is_bulk_in(epd))
- goto failed;
- epd = _desc->endpoint[2].desc;
- if (!usb_endpoint_is_bulk_out(epd))
+ result = usb_find_common_endpoints(iface_desc, _in, _out,
NULL, NULL);
+ if (result)
goto failed;
dev = interface_to_usbdev(interface);
@@ -96,6 +87,8 @@ static int prism2sta_probe_usb(struct usb_interface
*interface,
}
/* Initialize the hw data */
+ hw->endp_in = usb_rcvbulkpipe(dev, bulk_in->bEndpointAddress);
+ hw->endp_out = usb_sndbulkpipe(dev, bulk_out->bEndpointAddress);
hfa384x_create(hw, dev);
hw->wlandev = wlandev;
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API
On Sat, 25 Jul 2020 at 10:06, Ard Biesheuvel wrote: > > On Sat, 18 Jul 2020 at 11:18, Ard Biesheuvel wrote: > > > > On Fri, 3 Jul 2020 at 02:04, Ard Biesheuvel wrote: > > > > > > On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote: > > > > > > > > On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote: > > > > > > > > > > [+linux-wireless, Marcel Holtmann, and Denis Kenzior] > > > > > > > > > > On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote: > > > > > > Remove the generic ecb(arc4) skcipher, which is slightly cumbersome > > > > > > from > > > > > > a maintenance perspective, since it does not quite behave like other > > > > > > skciphers do in terms of key vs IV lifetime. Since we are leaving > > > > > > the > > > > > > library interface in place, which is used by the various WEP and > > > > > > TKIP > > > > > > implementations we have in the tree, we can safely drop this code > > > > > > now > > > > > > it no longer has any users. > > > > > > > > > > > > Signed-off-by: Ard Biesheuvel > > > > > > > > > > Last year there was a discussion where it was mentioned that iwd uses > > > > > "ecb(arc4)" via AF_ALG. So can we really remove it yet? > > > > > See > > > > > https://lkml.kernel.org/r/97bb95f6-4a4c-4984-9eab-6069e19b4...@holtmann.org > > > > > Note that the code isn't in "iwd" itself but rather in "libell" which > > > > > iwd > > > > > depends on: https://git.kernel.org/pub/scm/libs/ell/ell.git/ > > > > > > > > > > Apparently it also uses md4 and ecb(des) too. > > > > > > > > > > > > > Ah yes, I remember now :-( > > > > > > > > > Marcel and Denis, what's your deprecation plan for these obsolete and > > > > > insecure > > > > > algorithms? > > > > > > > > > > > > > Given Denis's statement: > > > > > > > > It sounds to me like it was broken and should be fixed. So our vote / > > > > preference is to have ARC4 fixed to follow the proper semantics. We > > > > can deal with the kernel behavioral change on our end easily enough; > > > > the required workarounds are the worse evil. > > > > > > > > I would think that an ABI break is not the end of the world for them, > > > > and given how trivial it is to implement RC4 in C, the workaround > > > > should be to simply implement RC4 in user space, and not even bother > > > > trying to use AF_ALG to get at ecb(arc4) > > > > > > > > (same applies to md4 and ecb(des) btw) > > > > > > > > There will always be a long tail of use cases, and at some point, we > > > > just have to draw the line and remove obsolete and insecure cruft, > > > > especially when it impedes progress on other fronts. > > > > > > > > > > I have ported iwd to Nettle's LGPL 2.1 implementation of ARC4, and the > > > diffstat is > > > > > > src/crypto.c | 80 > > > src/main.c| 8 -- > > > unit/test-eapol.c | 3 +- > > > 3 files changed, 51 insertions(+), 40 deletions(-) > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/iwd.git/log/?h=arc4-cleanup > > > > Marcel, Denis, > > > > Do you have any objections to the ecb(arc4) skcipher being dropped > > from the kernel, given the fallback i proposed above (which is a much > > better way of doing rc4 in user space anyway)? > > > > For libell, I would suggest dropping rc4 entirely, once iwd stops > > relying on it, as using rc4 for tls is obsolete as well. > > Ping? Denis was kind enough to take the changes to iwd and libell that remove all dependencies on the ecb(arc4) skcipher exposed by the kernel, so we can at least deprecate it in the short term, and hopefully remove it entirely at a later stage. Perhaps we should introduce a Kconfig symbol that needs to be set to enable deprecated algorithms? That way, we can work with the distros to phase out the old junk that is piling up, but in a way that doesn't break people's systems. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] sched: Provide USF for the portable equipment.
Hi Dongdong
On 08/04/20 15:50, Dongdong Yang wrote:
> +What:/sys/devices/system/cpu/sched_usf
> + /sys/devices/system/cpu/sched_usf/sched_usf_non_ux_r
> + /sys/devices/system/cpu/sched_usf/sched_usf_up_l0_r
> + /sys/devices/system/cpu/sched_usf/sched_usf_down_r
> +Date:Aug 2020
> +Contact: Linux kernel mailing list
> +Description: User Sensitive Feedback factor auxiliary scheduling which
> + is providing more utils adjustment settings to the high level
> + by scenario identification.
> + sched_usf_non_ux_r:
> + The ratio of utils is cut down on screen off. The
> + default value is 0, which no util is adjusted on sugov
> + calculating utils to select cpufreq. Its range is
> + [-100 , 0]. If its value falls into [-50, 0), the half
> + of utils, which calculates cpufreq, shall be cut down.
> + If its value falls into [-100, -50), only a quarter of
> + utils are left to continue to calculate cpufreq.
> + It is expected to be set [-100, 0) once enter into the
> + identificated scenario, such as listen to music on
> + screen off, and recover to 0 on out of the scenario,
> + such as screen on.
> +
> + sched_usf_up_l0_r:
> + The ratio of utils is boost up on screen on. The
> + default value is 0, which no util is adjusted on sugov
> + calculates utils to select cpufreq. Its range is [0 ,
> 100].
> + If its value falls into (0, 50], a quarter of extra
> utils,
> + which calculate cpufreq, shall be added. If its value
> + falls into (50, 100], the half of extra utils are added
> + to continue to calculate cpufreq.
> + It is expected to be set (0, 100] once enter into the
> + identificated scenario, such as browsing videolet on
> + screen on, and recover to 0 on out of the scenario,
> + such as screen off or videolet into background.
> +
> + sched_usf_down_r:
> + The ratio of utils is cut down on screen on. The
> + default value is 0, which no util is adjusted on sugov
> + calculating utils to select cpufreq. Its range is
> + [-100 , 0]. If its value falls into [-50, 0), the half
> + of utils, which calculate cpufreq, shall be cut down.
> + If its value falls into [-100, -50), only a quarter of
> + utils are left to continue to calculate cpufreq.
> + It is expected to be set [-100, 0) once enter into the
> + identificated scenario, such as browsing videolet on
> + screen on, and recover to 0 on out of the scenario,
> + such as screen off or vidolet into background.
AFACS you're duplicating util clamp functionality here. You can already use
util clamp to boost tasks on screen on, and cap them on screen off. And extra
brownie points; you can already use that on android 4.19 and 5.4 kernels (I'm
assuming the battery device is android based, sorry).
Any reason why util clamp isn't giving you what you want?
To cap the system on screen off you need to
# Don't allow the util to go above 512
echo 512 > /proc/sys/kernel/sched_util_clamp_min
echo 512 > /proc/sys/kernel/sched_util_clamp_max
To boost the system on screen on, you need first to lift the capping done above
# Allow util to use the full range again
echo 1024 > /proc/sys/kernel/sched_util_clamp_min
echo 1024 > /proc/sys/kernel/sched_util_clamp_max
# This is pseudo C code
for_each_important_task(p) {
/*
* boost the task utilization to start from 512.
*/
sched_attr attr = {
.util_min = 512,
.util_max = 1024
};
sched_setattr(p, attr);
}
/* undo boosting once system has settled down */
for_each_important_task(p) {
/*
* reset util_min back to 0, or whatever value you want.
*/
sched_attr attr = {
.util_min = 0,
.util_max = 1024
};
sched_setattr(p, attr);
}
There's a cgroup API for util clamp too.
Thanks
--
Qais Yousef
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Add Mediatek High Frequency Manager Framework
Hi "hongxu.zhao",
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
url:
https://github.com/0day-ci/linux/commits/hongxu-zhao/staging-Add-Mediatek-High-Frequency-Manager-Framework/20200804-155814
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
5bbd90550da8f7bdac769b5825597e67183c9411
config: alpha-allyesconfig (attached as .config)
compiler: alpha-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=alpha
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/linux/kernel.h:11,
from drivers/staging/hf_manager/core/hf_manager.c:9:
drivers/staging/hf_manager/core/hf_manager.c: In function
'hf_manager_io_schedule':
>> include/linux/compiler.h:301:1: error: expected expression before 'do'
301 | do { \
| ^~
arch/alpha/include/asm/atomic.h:34:27: note: in expansion of macro
'WRITE_ONCE'
34 | #define atomic64_set(v,i) WRITE_ONCE((v)->counter, (i))
| ^~
drivers/staging/hf_manager/core/hf_manager.h:145:40: note: in expansion of
macro 'atomic64_set'
145 | #define set_interrupt_timestamp(m, t) (atomic64_set(>timestamp,
t))
|^~~~
drivers/staging/hf_manager/core/hf_manager.c:171:2: note: in expansion of
macro 'set_interrupt_timestamp'
171 | set_interrupt_timestamp(manager, timestamp);
| ^~~
vim +/do +301 include/linux/compiler.h
a5460b5e5fb826 Will Deacon 2019-12-16 299
9e343b467c7037 Will Deacon 2019-12-13 300 #define WRITE_ONCE(x, val)
\
9e343b467c7037 Will Deacon 2019-12-13 @301 do {
\
9e343b467c7037 Will Deacon 2019-12-13 302
compiletime_assert_rwonce_type(x); \
44b97dccb2291a Marco Elver 2020-05-21 303 __WRITE_ONCE(x, val);
\
9e343b467c7037 Will Deacon 2019-12-13 304 } while (0)
9e343b467c7037 Will Deacon 2019-12-13 305
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: greybus: audio: Uninitialized variable in gbaudio_remove_controls()
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
---
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);
--
2.27.0
___
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 Tue, Aug 04, 2020 at 03:50:35PM +0800, Dongdong Yang wrote: > +What:/sys/devices/system/cpu/sched_usf > + /sys/devices/system/cpu/sched_usf/sched_usf_non_ux_r > + /sys/devices/system/cpu/sched_usf/sched_usf_up_l0_r > + /sys/devices/system/cpu/sched_usf/sched_usf_down_r > +Date:Aug 2020 > +Contact: Linux kernel mailing list > +Description: User Sensitive Feedback factor auxiliary scheduling which > + is providing more utils adjustment settings to the high level > + by scenario identification. > + sched_usf_non_ux_r: > + The ratio of utils is cut down on screen off. The > + default value is 0, which no util is adjusted on sugov > + calculating utils to select cpufreq. Its range is > + [-100 , 0]. If its value falls into [-50, 0), the half > + of utils, which calculates cpufreq, shall be cut down. > + If its value falls into [-100, -50), only a quarter of > + utils are left to continue to calculate cpufreq. > + It is expected to be set [-100, 0) once enter into the > + identificated scenario, such as listen to music on > + screen off, and recover to 0 on out of the scenario, > + such as screen on. > + > + sched_usf_up_l0_r: > + The ratio of utils is boost up on screen on. The > + default value is 0, which no util is adjusted on sugov > + calculates utils to select cpufreq. Its range is [0 , > 100]. > + If its value falls into (0, 50], a quarter of extra > utils, > + which calculate cpufreq, shall be added. If its value > + falls into (50, 100], the half of extra utils are added > + to continue to calculate cpufreq. > + It is expected to be set (0, 100] once enter into the > + identificated scenario, such as browsing videolet on > + screen on, and recover to 0 on out of the scenario, > + such as screen off or videolet into background. > + > + sched_usf_down_r: > + The ratio of utils is cut down on screen on. The > + default value is 0, which no util is adjusted on sugov > + calculating utils to select cpufreq. Its range is > + [-100 , 0]. If its value falls into [-50, 0), the half > + of utils, which calculate cpufreq, shall be cut down. > + If its value falls into [-100, -50), only a quarter of > + utils are left to continue to calculate cpufreq. > + It is expected to be set [-100, 0) once enter into the > + identificated scenario, such as browsing videolet on > + screen on, and recover to 0 on out of the scenario, > + such as screen off or vidolet into background. I hate the names, they're a bunch of random letters. Maybe if you strip the 'sched_usf' prefix, on account on these files being in a directory by the same name, you'll have additional budget for readable names? Also, I detest 100, 100 sucks. Use something sane, like 128. Also, I'm not at all sure I understand the text. Also, nothing explains how any of this is supposed to be working on an SMP system. Please advice how this makes sense if you have 64 CPUs. My desktop has a screen, so giving feedback should work, no? > diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig > index e917501..a21c6ad 100644 > --- a/drivers/cpufreq/Kconfig > +++ b/drivers/cpufreq/Kconfig > @@ -224,6 +224,17 @@ config CPUFREQ_DT_PLATDEV > > If in doubt, say N. > > +config SCHED_USF > + bool "User Sensitive Factors for Scheduler" 'bool' means this cannot be a module, yet see below. > + depends on CPU_FREQ_GOV_SCHEDUTIL && FB I really hate how this is a special purpose hack for framebuffer. We don't do special purpose hacks like that. So you have something that only 'works' for small machines, small number of tasks, and requires FB. NAK, we don't do that upstream. > + 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. > + > if X86 > source "drivers/cpufreq/Kconfig.x86" > endif > diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h > index ed168b0..d5e20b7 100644 > --- a/include/trace/events/sched.h > +++ b/include/trace/events/sched.h > @@ -488,6 +488,41 @@ TRACE_EVENT(sched_process_hang, >
SPENDE
Ich habe eine Spende von 5,5 Millionen Euro für Sie. Bitte antworten Sie. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Add Mediatek High Frequency Manager Framework
On Tue, Aug 04, 2020 at 03:52:49PM +0800, hongxu.zhao wrote: > Add a new sensor framework into linux kernel which can support multi client > request sensor data. > There are the following features: > 1.Ringbuffer between manager and client; > 2.Kernel space user interface; > 3.User space user interface with syscall; > 4.Each client hang detect mechanism; > 5.Polling timer management in framework no need driver concern; > 6.Polling kthread work intergrated into a single kthread > worker to save system resources in framework no need driver concern; > 7.Proc file system to show manager device and client details; > 8.Compitable with android and widely used in many mediatek platform > products; > > Change-Id: I6361cdc2d51de50f66eede7df099c4575e7ec473 Did you not run checkpatch.pl on this? :) No need for change-id here. But, most importantly, why is this in drivers/staging? What keeps it from being in the "real" part of the kernel? I need a TODO file in the directory of the driver listing what remains to be done and who is responsible for doing this work and reviewing patches. Can you resend this with that file added and the Change-id removed? Also, why not just use the IIO interface, why are you creating yet-another api for sensors? We already have 2, making a third seems like something that guarantees this will never be mergable to the correct part of the kernel. And finally, /proc/ is not for devices, that is what sysfs is for, please use that. thanks, greg k-h ___ 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 Tue, Aug 04, 2020 at 03:50:35PM +0800, Dongdong Yang wrote:
Comments on code stuff only, not if this is actually a valid thing to be
doing at all:
> --- /dev/null
> +++ b/kernel/sched/usf.c
> @@ -0,0 +1,294 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * 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.
No need for the two paragraph "boiler plate" license text now that you
have a SPDX line, please remove them.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "sched.h"
> +
> +#define BOOST_MIN_V -100
> +#define BOOST_MAX_V 100
> +#define LEVEL_TOP 3
> +
> +#define USF_TAG "[usf_sched]"
Please pr_fmt instead.
> +
> +DEFINE_PER_CPU(unsigned long[PID_MAX_DEFAULT], task_hist_nivcsw);
> +
> +static struct {
> + bool is_sched_usf_enabled;
> + bool is_screen_on;
> + int sysctl_sched_usf_up_l0;
> + int sysctl_sched_usf_down;
> + int sysctl_sched_usf_non_ux;
> + int usf_up_l0;
> + int usf_down;
> + int usf_non_ux;
> +} usf_vdev;
> +
> +void adjust_task_pred_demand(int cpuid,
> + unsigned long *util,
> + struct rq *rq)
> +{
> + /* sysctl_sched_latency/sysctl_sched_min_granularity */
> + u32 bl_sw_num = 3;
> +
> + if (!usf_vdev.is_sched_usf_enabled || !rq || !rq->curr ||
> + (rq->curr->pid >= PID_MAX_DEFAULT))
> + return;
> +
> + if (usf_vdev.is_screen_on) {
> + if (rq->curr->nivcsw >
> + (per_cpu(task_hist_nivcsw, cpuid)[rq->curr->pid]
> + + bl_sw_num + 1)) {
> + (*util) += (*util) >> usf_vdev.usf_up_l0;
> + } else if (rq->curr->nivcsw <
> +(per_cpu(task_hist_nivcsw, cpuid)[rq->curr->pid]
> + + bl_sw_num - 1) && (rq->nr_running < bl_sw_num)) {
> + (*util) >>= usf_vdev.usf_down;
> + }
> + per_cpu(task_hist_nivcsw, cpuid)[rq->curr->pid] =
> + rq->curr->nivcsw;
> + } else if (rq->curr->mm) {
> + (*util) >>= usf_vdev.usf_non_ux;
> + }
> +
> + trace_sched_usf_adjust_utils(cpuid, usf_vdev.usf_up_l0,
> + usf_vdev.usf_down,
> + usf_vdev.usf_non_ux, *util);
> +}
> +
> +static int usf_lcd_notifier(struct notifier_block *nb,
> + unsigned long val, void *data)
> +{
> + struct fb_event *evdata = data;
> + unsigned int blank;
> +
> + if (!evdata)
> + return 0;
> +
> + if (val != FB_EVENT_BLANK)
> + return 0;
> +
> + if (evdata->data && val == FB_EVENT_BLANK) {
> + blank = *(int *)(evdata->data);
> +
> + switch (blank) {
> + case FB_BLANK_POWERDOWN:
> + usf_vdev.is_screen_on = false;
> + if (usf_vdev.sysctl_sched_usf_non_ux != 0)
> + static_branch_enable(_task_pred_set);
> + else
> + static_branch_disable(_task_pred_set);
> +
> + break;
> +
> + case FB_BLANK_UNBLANK:
> + usf_vdev.is_screen_on = true;
> + if (usf_vdev.sysctl_sched_usf_up_l0 != 0 ||
> + usf_vdev.sysctl_sched_usf_down != 0)
> + static_branch_enable(_task_pred_set);
> + else
> + static_branch_disable(_task_pred_set);
> + break;
> + default:
> + break;
> + }
> +
> + usf_vdev.is_sched_usf_enabled = true;
> + pr_info("%s : usf_vdev.is_screen_on:%b\n",
> + __func__, usf_vdev.is_screen_on);
> + }
> + return NOTIFY_OK;
> +}
> +
> +static struct notifier_block usf_lcd_nb = {
> + .notifier_call = usf_lcd_notifier,
> + .priority = INT_MAX,
> +};
> +
> +static ssize_t store_sched_usf_up_l0_r(struct kobject *kobj,
> +struct kobj_attribute *attr,
> +const char *buf, size_t count)
> +{
> + int val = 0;
> + int ret = 0;
> +
> + ret = kstrtoint(buf, 0, );
> + if (ret)
> + return ret;
> +
> + if (val == 0) {
> +
[PATCH] staging: Add Mediatek High Frequency Manager Framework
Add a new sensor framework into linux kernel which can support multi client request sensor data. There are the following features: 1.Ringbuffer between manager and client; 2.Kernel space user interface; 3.User space user interface with syscall; 4.Each client hang detect mechanism; 5.Polling timer management in framework no need driver concern; 6.Polling kthread work intergrated into a single kthread worker to save system resources in framework no need driver concern; 7.Proc file system to show manager device and client details; 8.Compitable with android and widely used in many mediatek platform products; Change-Id: I6361cdc2d51de50f66eede7df099c4575e7ec473 Signed-off-by: hongxu.zhao --- drivers/staging/Kconfig |2 + drivers/staging/Makefile |1 + drivers/staging/hf_manager/Kconfig| 11 + drivers/staging/hf_manager/Makefile |7 + drivers/staging/hf_manager/core/Makefile |6 + drivers/staging/hf_manager/core/hf_manager.c | 1419 + drivers/staging/hf_manager/core/hf_manager.h | 181 +++ .../staging/hf_manager/core/hf_sensor_io.h| 69 + .../staging/hf_manager/core/hf_sensor_type.h | 56 + drivers/staging/hf_manager/test/Makefile | 11 + drivers/staging/hf_manager/test/test.c| 182 +++ drivers/staging/hf_manager/test/test_app.c| 174 ++ drivers/staging/hf_manager/test/test_app1.c | 143 ++ drivers/staging/hf_manager/test/test_app2.c | 162 ++ 14 files changed, 2424 insertions(+) create mode 100644 drivers/staging/hf_manager/Kconfig create mode 100644 drivers/staging/hf_manager/Makefile create mode 100644 drivers/staging/hf_manager/core/Makefile create mode 100644 drivers/staging/hf_manager/core/hf_manager.c create mode 100644 drivers/staging/hf_manager/core/hf_manager.h create mode 100644 drivers/staging/hf_manager/core/hf_sensor_io.h create mode 100644 drivers/staging/hf_manager/core/hf_sensor_type.h create mode 100644 drivers/staging/hf_manager/test/Makefile create mode 100644 drivers/staging/hf_manager/test/test.c create mode 100644 drivers/staging/hf_manager/test/test_app.c create mode 100644 drivers/staging/hf_manager/test/test_app1.c create mode 100644 drivers/staging/hf_manager/test/test_app2.c diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index 4ec5528f89fa..ef8f9dc957b3 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -120,4 +120,6 @@ source "drivers/staging/qlge/Kconfig" source "drivers/staging/wfx/Kconfig" +source "drivers/staging/hf_manager/Kconfig" + endif # STAGING diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index 4d34198151b3..64bf769c0131 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -50,3 +50,4 @@ obj-$(CONFIG_FIELDBUS_DEV) += fieldbus/ obj-$(CONFIG_KPC2000) += kpc2000/ obj-$(CONFIG_QLGE) += qlge/ obj-$(CONFIG_WFX) += wfx/ +obj-$(CONFIG_HF_MANAGER) += hf_manager/ diff --git a/drivers/staging/hf_manager/Kconfig b/drivers/staging/hf_manager/Kconfig new file mode 100644 index ..af8914c97af8 --- /dev/null +++ b/drivers/staging/hf_manager/Kconfig @@ -0,0 +1,11 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# high frequency manager subsystem configuration +# + +menuconfig HF_MANAGER + tristate "High frequency manager support" + help + The high frequency manager subsystem provides a unified framework for + drivers for many different types of embedded mems sensors using a + number of different physical interfaces (i2c, spi, etc). \ No newline at end of file diff --git a/drivers/staging/hf_manager/Makefile b/drivers/staging/hf_manager/Makefile new file mode 100644 index ..4f00192801c1 --- /dev/null +++ b/drivers/staging/hf_manager/Makefile @@ -0,0 +1,7 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Makefile for high frequency manager. +# + +obj-y += core/ +# obj-y += test/ diff --git a/drivers/staging/hf_manager/core/Makefile b/drivers/staging/hf_manager/core/Makefile new file mode 100644 index ..23a7cc349363 --- /dev/null +++ b/drivers/staging/hf_manager/core/Makefile @@ -0,0 +1,6 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Makefile for high frequency manager core +# + +obj-y += hf_manager.o diff --git a/drivers/staging/hf_manager/core/hf_manager.c b/drivers/staging/hf_manager/core/hf_manager.c new file mode 100644 index ..a4d4298d5265 --- /dev/null +++ b/drivers/staging/hf_manager/core/hf_manager.c @@ -0,0 +1,1419 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (c) 2020 MediaTek Inc. + * Author: Hongxu Zhao + */ + +#define pr_fmt(fmt) "[hf_manager]" fmt + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "hf_manager.h" + +static const struct coordinate
[PATCH v4] 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 utils 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_task_pred_demand shall not be invoked. Once sched_usf_up_l0_r sched_usf_down_r or sched_usf_non_ux_r be set, adjust_task_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 sched_usf_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 --- Documentation/ABI/testing/sysfs-devices-system-cpu | 48 drivers/cpufreq/Kconfig| 11 + include/trace/events/sched.h | 35 +++ kernel/sched/Makefile | 1 + kernel/sched/cpufreq_schedutil.c | 3 + kernel/sched/sched.h | 10 + kernel/sched/usf.c | 294 + 7 files changed, 402 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..e299418 100644 ---
[PATCH v4] 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 utils 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 "sched_usf_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 "sched_usf_up_l0_r" and "sched_usf_down_r" have been provided to adjust the utils according to high level identified scenario to alloc the cpufreq in time. 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 | 48 drivers/cpufreq/Kconfig| 11 + include/trace/events/sched.h | 35 +++ kernel/sched/Makefile | 1 + kernel/sched/cpufreq_schedutil.c | 3 + kernel/sched/sched.h | 10 + kernel/sched/usf.c | 294 + 7 files changed, 402 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
Re: [PATCH v3] Provide USF for the portable equipment.
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, Aug 04, 2020 at 03:34:25PM +0800, Dongdong Yang wrote: > Appreciate Viresh for your help. I thought Peter's NAK was only for the > initial version. I am going to upload the verified version 4. Could you > please kindly help to further review? > > 1. Motivation > = > > The power consumption and UI response are more cared for by the portable > equipment users. That's not true, everyone cares about this. > USF(User Sensitive Feedback factor) auxiliary cpufreq > governor > is providing more utils adjustment settings to the high level by scenario > identification. Odd line-wrapping :( And what do you mean by "more utils adjustment settings to the high level by scenario identification"? I can not parse that at all. > 2. Introduction > === > > The USF auxiliary scheduling is based on FrameBuffer and schdeutil cpufreq > governor to adjust utils by the identificated scenario from User Space. What is "adjust utils"? And why is "User Space" in caps? > It is for portable equipment which "screen off" status stands for no request > from the user, however, the kernel is still expected to notify the user for > UI in > time on modem, network or powerkey events occur. In order to save power, the > sysfs inode nonux is provided to set the utils down level on userspace > tasks. Having custom sysfs apis is almost never a good idea. Do other cpufreq governers do this? > In addition, the portable equipment users usually heavily interact with > devices > by touch, and other peripherals. On "screen on" status, The boost preemptive > counts are marking the load requirement urgent, vice versa. USF provides up > and > down sysfs inodes to adjust utils according to such feedback factor and the > level setting from the user space identified scenario. > > adjust_task_pred_set is as the switch to enable or disable the adjustment. > If no USF sysfs inodes is set and no screen on or off event be received, > adjust_task_pred_demand shall not be executed. > > 3. System wide settings > === > > sched_usf_non_ux_r: > The ratio of utils is cut down on screen off. The default value is > 0, The line-wrapping makes it almost impossible to read here, can you fix that up? > which no util be adjusted on sugov calculating utils to select "sugov"? > cpufreq. > Its range is [-100 , 0]. If its value falls into [-50, 0), the half > of > utils, which calculates cpufreq, shall be cut down. If its value > falls > into [-100, -50), only a quarter of utils be left to continue to > calculates cpufreq. > It is expected to be set [-100, 0) once enter into the identificated > scenario, such as listen to music on screen off, and recover to 0 on > out of the scenario, such as screen on. sysfs files are "one value per file", please do not parse such complex things in the kernel. > > sched_usf_up_l0_r: > The ratio of utils is boosted up on screen on. The default value is > 0, > which no util be adjusted on sugov calculates utils to select > cpufreq. > Its range is [0 , 100]. If its value falls into (0, 50], a quarter > of > extra utils, which calculates cpufreq, shall be added. If its value > falls into (50, 100], the half of extra utils be added to continue > to > calculates cpufreq. > It is expected to be set (0, 100] once enter into the identificated > scenario, such as browsing videolet on screen on, and recover to 0 > on > out of the scenario, such as screen off or videolet into background. > > sched_usf_down_r: > The ratio of utils is cut down on screen on. The default value is 0, > which no util be adjusted on sugov calculating utils to select > cpufreq. > Its range is [-100 , 0]. If its value falls into [-50, 0), the half > of > utils, which calculates cpufreq, shall be cut down. If its value > falls > into [-100, -50), only a quarter of utils be left to continue to > calculates cpufreq. > It is expected to be set [-100, 0) once enter into the identificated > scenario, such as browsing videolet on screen on, and recover to 0 > on > out of the scenario, such as screen off or vidolet into background. Why can't all of these work automatically? Why do you need userspace interaction here? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
