Re: [PATCH] net/mlx5: reduce stack usage in qp_read_field
On Thu, Apr 30, 2020 at 04:37:14PM +0200, Arnd Bergmann wrote:
> On Thu, Apr 30, 2020 at 7:22 AM Leon Romanovsky wrote:
> > On Tue, Apr 28, 2020 at 11:23:47PM +0200, Arnd Bergmann wrote:
> > > Moving the mlx5_ifc_query_qp_out_bits structure on the stack was a bit
> > > excessive and now causes the compiler to complain on 32-bit architectures:
> > >
> > > drivers/net/ethernet/mellanox/mlx5/core/debugfs.c: In function
> > > 'qp_read_field':
> > > drivers/net/ethernet/mellanox/mlx5/core/debugfs.c:274:1: error: the frame
> > > size of 1104 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
> > >
> > > Revert the previous patch partially to use dynamically allocation as
> > > the code did before. Unfortunately there is no good error handling
> > > in case the allocation fails.
> > >
> > > Fixes: 57a6c5e992f5 ("net/mlx5: Replace hand written QP context struct
> > > with automatic getters")
> > > Signed-off-by: Arnd Bergmann
> > > ---
> > > drivers/net/ethernet/mellanox/mlx5/core/debugfs.c | 12 +---
> > > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
> > Thanks Arnd, I'll pick it to mlx5-next.
> >
> > I was under impression that the frame size was increased a long
> > time ago. Is this 1K limit still effective for all archs?
> > Or is it is 32-bit leftover?
>
> I got the output on a 32-bit build, but that doesn't make the code
> right on 64-bit.
>
> While warning limit is generally 1024 bytes for 32-bit architectures,
> and 2048 bytes fro 64-bit architectures, we should probably
> reduce the latter to something like 1280 bytes and fix up the
> warnings that introduces.
It a chicken and an egg problem, I tried to use default frame size, but
the output of my kernel build was constantly flooded with those warnings
and made hard to spot real issues in the code I developed.
Thanks
>
> Generally speaking, I'd say a function using more than a few hundred
> bytes tends to be a bad idea, but we can't warn about those without
> also warning about the handful of cases that do it for a good reason
> and using close to 1024 bytes on 32 bit systems or a little more on
> 64-bit systems, in places that are known not to have deep call chains.
>
>Arnd
Re: linux-next: manual merge of the net-next tree with the net tree
On Fri, May 01, 2020 at 12:48:36PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c
>
> between commit:
>
> 8075411d93b6 ("net/mlx5: DR, On creation set CQ's arm_db member to right
> value")
>
> from the net tree and commit:
>
> 73a75b96fc9a ("net/mlx5: Remove empty QP and CQ events handlers")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
Thanks for the resolution.
>
> diff --cc drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c
> index 18719acb7e54,c4ed25bb9ac8..
> --- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c
> @@@ -689,18 -693,6 +693,12 @@@ static int dr_prepare_qp_to_rts(struct
> return 0;
> }
>
> - static void dr_cq_event(struct mlx5_core_cq *mcq,
> - enum mlx5_event event)
> - {
> - pr_info("CQ event %u on CQ #%u\n", event, mcq->cqn);
> - }
> -
> +static void dr_cq_complete(struct mlx5_core_cq *mcq,
> + struct mlx5_eqe *eqe)
> +{
> +pr_err("CQ completion CQ: #%u\n", mcq->cqn);
> +}
> +
Saeed,
Please pay attention that commit 8075411d93b6
("net/mlx5: DR, On creation set CQ's arm_db member to right value")
mentioned by Stephen is not accurate. ".comp" callback shouldn't be
called if it is NULL, so unclear what you get by adding such pr_err().
Thanks
signature.asc
Description: PGP signature
Re: [PATCH 2/2] staging: vt6655: fix LONG_LINE warning
On Sun, 2020-05-03 at 00:16 +0200, Matej Dujava wrote:
> This patch will fix LONG_LINE error from checkpatch, by createing temporary
> variable so call to the function is not in if/else block.
[]
> diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
[]
> @@ -164,16 +164,24 @@ s_uGetTxRsvTime(
> )
> {
> unsigned int uDataTime, uAckTime;
> + unsigned short basic_rate;
>
> uDataTime = bb_get_frame_time(pDevice->byPreambleType, byPktType,
> cbFrameLength, wRate);
>
> if (!bNeedAck)
> return uDataTime;
>
> - if (byPktType == PK_TYPE_11B) /* llb,CCK mode */
> - uAckTime = bb_get_frame_time(pDevice->byPreambleType,
> byPktType, 14, (unsigned short)pDevice->byTopCCKBasicRate);
> - else /* 11g 2.4G OFDM mode & 11a 5G OFDM mode */
> - uAckTime = bb_get_frame_time(pDevice->byPreambleType,
> byPktType, 14, (unsigned short)pDevice->byTopOFDMBasicRate);
> + /*
> + * CCK mode - 11b
> + * OFDM mode - 11g 2.4G & 11a 5G
> + */
> + if (byPktType == PK_TYPE_11B)
> + basic_rate = (unsigned short)pDevice->byTopCCKBasicRate;
> + else
> + basic_rate = (unsigned short)pDevice->byTopOFDMBasicRate;
> +
> + uAckTime = bb_get_frame_time(pDevice->byPreambleType, byPktType, 14,
> + basic_rate);
>
> return uDataTime + pDevice->uSIFS + uAckTime;
> }
perhaps simpler using a ?:
uAckTime = bb_get_frame_time(pDevice->byPreambleType, byPktType, 14,
byPktType == PK_TYPE_11B
? pDevice->byTopCCKBasicRate
: pDevice->byTopOFDMBasicRate);
the casts aren't necessary either as both by... fields are u8
My Dear in the lord
My Dear in the lord My name is Mrs. Mina A. Brunel I am a Norway Citizen who is living in Burkina Faso, I am married to Mr. Brunel Patrice, a politicians who owns a small gold company in Burkina Faso; He died of Leprosy and Radesyge, in year February 2010, During his lifetime he deposited the sum of € 8.5 Million Euro) Eight million, Five hundred thousand Euros in a bank in Ouagadougou the capital city of of Burkina in West Africa. The money was from the sale of his company and death benefits payment and entitlements of my deceased husband by his company. I am sending you this message with heavy tears in my eyes and great sorrow in my heart, and also praying that it will reach you in good health because I am not in good health, I sleep every night without knowing if I may be alive to see the next day. I am suffering from long time cancer and presently I am partially suffering from Leprosy, which has become difficult for me to move around. I was married to my late husband for more than 6 years without having a child and my doctor confided that I have less chance to live, having to know when the cup of death will come, I decided to contact you to claim the fund since I don't have any relation I grew up from an orphanage home. I have decided to donate this money for the support of helping Motherless babies/Less privileged/Widows and churches also to build the house of God because I am dying and diagnosed with cancer for about 3 years ago. I have decided to donate from what I have inherited from my late husband to you for the good work of Almighty God; I will be going in for an operation surgery soon. Now I want you to stand as my next of kin to claim the funds for charity purposes. Because of this money remains unclaimed after my death, the bank executives or the government will take the money as unclaimed fund and maybe use it for selfishness and worthless ventures, I need a very honest person who can claim this money and use it for Charity works, for orphanages, widows and also build schools and churches for less privilege that will be named after my late husband and my name. I need your urgent answer to know if you will be able to execute this project, and I will give you more information on how the fund will be transferred to your bank account or online banking. Thanks Mrs. Mina A. Brunel
[PATCH] perf trace: add default value for opt 'call-graph'
The documentation says the default value of call-graph.record_mode is 'fp'.
But actually we never can omit value of call-graph parameter. This patch
can fix this issue.
Meanwhile, this patch adds a short name '-g' for opt 'call-graph' since it's
very useful.
Signed-off-by: Changbin Du
---
tools/perf/builtin-trace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 01d542007c8b..21a9656021a0 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -4754,9 +4754,9 @@ int cmd_trace(int argc, const char **argv)
"Trace pagefaults", parse_pagefaults, "maj"),
OPT_BOOLEAN(0, "syscalls", _syscalls, "Trace syscalls"),
OPT_BOOLEAN('f', "force", , "don't complain, do it"),
- OPT_CALLBACK(0, "call-graph", ,
+ OPT_CALLBACK_DEFAULT('g', "call-graph", ,
"record_mode[,record_size]", record_callchain_help,
-_parse_callchain_opt),
+_parse_callchain_opt, "fp"),
OPT_BOOLEAN(0, "libtraceevent_print", _print,
"Use libtraceevent to print the tracepoint arguments."),
OPT_BOOLEAN(0, "kernel-syscall-graph", _syscallchains,
--
2.17.1
[PATCH v2] scripts: headers_install: Exit with error on config leak
Misuse of CONFIG_* in UAPI headers should result in an error as it exposes configuration of different targets to userspace. Signed-off-by: Siddharth Gupta --- scripts/headers_install.sh | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh index a07668a..94a8335 100755 --- a/scripts/headers_install.sh +++ b/scripts/headers_install.sh @@ -64,7 +64,7 @@ configs=$(sed -e ' d ' $OUTFILE) -# The entries in the following list are not warned. +# The entries in the following list do not result in an error. # Please do not add a new entry. This list is only for existing ones. # The list will be reduced gradually, and deleted eventually. (hopefully) # @@ -98,18 +98,19 @@ include/uapi/linux/raw.h:CONFIG_MAX_RAW_DEVS for c in $configs do - warn=1 + leak_error=1 for ignore in $config_leak_ignores do if echo "$INFILE:$c" | grep -q "$ignore$"; then - warn= + leak_error= break fi done - if [ "$warn" = 1 ]; then - echo "warning: $INFILE: leak $c to user-space" >&2 + if [ "$leak_error" = 1 ]; then + echo "error: $INFILE: leak $c to user-space" >&2 + exit 1 fi done -- Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] scripts: headers_install: Exit with error on config leak
Sure I will make the recommended changes and send a v2 of the patch. Thanks, Siddharth On 5/2/2020 8:03 AM, Masahiro Yamada wrote: On Sat, May 2, 2020 at 6:55 AM Siddharth Gupta wrote: Misuse of CONFIG_* in UAPI headers should result in an error as it exposes configuration of different targets to userspace. Signed-off-by: Siddharth Gupta --- scripts/headers_install.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh index a07668a..bd6c93a 100755 --- a/scripts/headers_install.sh +++ b/scripts/headers_install.sh @@ -109,7 +109,8 @@ do done if [ "$warn" = 1 ]; then - echo "warning: $INFILE: leak $c to user-space" >&2 + echo "error: $INFILE: leak $c to user-space" >&2 + exit 1 fi done If you want to change this, please update the comment at line 67. Also, rename the variable $warn to something else, $error or $leak_error, etc. ?
Re: [PATCH V1 09/10] arch/kmap: Define kmap_atomic_prot() for all arch's
On Fri, May 01, 2020 at 04:20:20AM +0100, Al Viro wrote:
> On Fri, May 01, 2020 at 03:37:34AM +0100, Al Viro wrote:
> > On Thu, Apr 30, 2020 at 01:38:44PM -0700, ira.we...@intel.com wrote:
> >
> > > -static inline void *kmap_atomic(struct page *page)
> > > +static inline void *kmap_atomic_prot(struct page *page, pgprot_t prot)
> > > {
> > > preempt_disable();
> > > pagefault_disable();
> > > if (!PageHighMem(page))
> > > return page_address(page);
> > > - return kmap_atomic_high(page);
> > > + return kmap_atomic_high_prot(page, prot);
> > > }
> > > +#define kmap_atomic(page)kmap_atomic_prot(page, kmap_prot)
> >
> > OK, so it *was* just a bisect hazard - you return to original semantics
> > wrt preempt_disable()...
>
> FWIW, how about doing the following: just before #5/10 have a patch
> that would touch only microblaze, ppc and x86 splitting their
> kmap_atomic_prot() into an inline helper + kmap_atomic_high_prot().
> Then your #5 would leave their kmap_atomic_prot() as-is (it would
> use kmap_atomic_prot_high() instead). The rest of the series plays
> out pretty much the same way it does now, and wrappers on those
> 3 architectures would go away when an identical generic one is
> introduced in this commit (#9/10).
>
> AFAICS, that would avoid the bisect hazard and might even end
> up with less noise in the patches...
This works. V2 coming out shortly.
Thanks for catching this,
Ira
[PATCH] Staging: comedi: drivers: ni_pcimio: Fix variable name
Fixed a variable name that was Camel case Signed-off-by: Eric Yu --- drivers/staging/comedi/drivers/ni_pcimio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/comedi/drivers/ni_pcimio.c b/drivers/staging/comedi/drivers/ni_pcimio.c index 7c82d5f9778f..c1d70eec24ab 100644 --- a/drivers/staging/comedi/drivers/ni_pcimio.c +++ b/drivers/staging/comedi/drivers/ni_pcimio.c @@ -1214,7 +1214,7 @@ static void m_series_init_eeprom_buffer(struct comedi_device *dev) struct ni_private *devpriv = dev->private; struct mite *mite = devpriv->mite; resource_size_t daq_phys_addr; - static const int Start_Cal_EEPROM = 0x400; + static const int start_cal_eeprom = 0x400; static const unsigned int window_size = 10; unsigned int old_iodwbsr_bits; unsigned int old_iodwbsr1_bits; @@ -1234,7 +1234,7 @@ static void m_series_init_eeprom_buffer(struct comedi_device *dev) writel(0xf, mite->mmio + 0x30); for (i = 0; i < M_SERIES_EEPROM_SIZE; ++i) - devpriv->eeprom_buffer[i] = ni_readb(dev, Start_Cal_EEPROM + i); + devpriv->eeprom_buffer[i] = ni_readb(dev, start_cal_eeprom + i); writel(old_iodwbsr1_bits, mite->mmio + MITE_IODWBSR_1); writel(old_iodwbsr_bits, mite->mmio + MITE_IODWBSR); -- 2.26.2
Re: [PATCH v3 2/5] scsi: ufs: add "index" in parameter list of ufshcd_query_flag()
On 2020-05-01 22:38, Stanley Chu wrote:
For preparation of LU Dedicated buffer mode support on WriteBooster
feature, "index" parameter shall be added and allowed to be specified
by callers.
Signed-off-by: Stanley Chu
Reviewed-by: Bean Huo
Reviewed-by: Can Guo
---
drivers/scsi/ufs/ufs-sysfs.c | 2 +-
drivers/scsi/ufs/ufshcd.c| 28 +++-
drivers/scsi/ufs/ufshcd.h| 2 +-
3 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-sysfs.c
b/drivers/scsi/ufs/ufs-sysfs.c
index 93484408bc40..b86b6a40d7e6 100644
--- a/drivers/scsi/ufs/ufs-sysfs.c
+++ b/drivers/scsi/ufs/ufs-sysfs.c
@@ -631,7 +631,7 @@ static ssize_t _name##_show(struct device
*dev,\
struct ufs_hba *hba = dev_get_drvdata(dev); \
pm_runtime_get_sync(hba->dev); \
ret = ufshcd_query_flag(hba, UPIU_QUERY_OPCODE_READ_FLAG, \
- QUERY_FLAG_IDN##_uname, ); \
+ QUERY_FLAG_IDN##_uname, 0, ); \
pm_runtime_put_sync(hba->dev); \
if (ret)\
return -EINVAL; \
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index c6668799d956..f23705379b7d 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2784,13 +2784,13 @@ static inline void ufshcd_init_query(struct
ufs_hba *hba,
}
static int ufshcd_query_flag_retry(struct ufs_hba *hba,
- enum query_opcode opcode, enum flag_idn idn, bool *flag_res)
+ enum query_opcode opcode, enum flag_idn idn, u8 index, bool
*flag_res)
{
int ret;
int retries;
for (retries = 0; retries < QUERY_REQ_RETRIES; retries++) {
- ret = ufshcd_query_flag(hba, opcode, idn, flag_res);
+ ret = ufshcd_query_flag(hba, opcode, idn, index, flag_res);
if (ret)
dev_dbg(hba->dev,
"%s: failed with error %d, retries %d\n",
@@ -2811,16 +2811,17 @@ static int ufshcd_query_flag_retry(struct
ufs_hba *hba,
* @hba: per-adapter instance
* @opcode: flag query to perform
* @idn: flag idn to access
+ * @index: flag index to access
* @flag_res: the flag value after the query request completes
*
* Returns 0 for success, non-zero in case of failure
*/
int ufshcd_query_flag(struct ufs_hba *hba, enum query_opcode opcode,
- enum flag_idn idn, bool *flag_res)
+ enum flag_idn idn, u8 index, bool *flag_res)
{
struct ufs_query_req *request = NULL;
struct ufs_query_res *response = NULL;
- int err, index = 0, selector = 0;
+ int err, selector = 0;
int timeout = QUERY_REQ_TIMEOUT;
BUG_ON(!hba);
@@ -4177,7 +4178,7 @@ static int ufshcd_complete_dev_init(struct
ufs_hba *hba)
bool flag_res = true;
err = ufshcd_query_flag_retry(hba, UPIU_QUERY_OPCODE_SET_FLAG,
- QUERY_FLAG_IDN_FDEVICEINIT, NULL);
+ QUERY_FLAG_IDN_FDEVICEINIT, 0, NULL);
if (err) {
dev_err(hba->dev,
"%s setting fDeviceInit flag failed with error %d\n",
@@ -4188,7 +4189,7 @@ static int ufshcd_complete_dev_init(struct
ufs_hba *hba)
/* poll for max. 1000 iterations for fDeviceInit flag to clear */
for (i = 0; i < 1000 && !err && flag_res; i++)
err = ufshcd_query_flag_retry(hba, UPIU_QUERY_OPCODE_READ_FLAG,
- QUERY_FLAG_IDN_FDEVICEINIT, _res);
+ QUERY_FLAG_IDN_FDEVICEINIT, 0, _res);
if (err)
dev_err(hba->dev,
@@ -5003,7 +5004,7 @@ static int ufshcd_enable_auto_bkops(struct
ufs_hba *hba)
goto out;
err = ufshcd_query_flag_retry(hba, UPIU_QUERY_OPCODE_SET_FLAG,
- QUERY_FLAG_IDN_BKOPS_EN, NULL);
+ QUERY_FLAG_IDN_BKOPS_EN, 0, NULL);
if (err) {
dev_err(hba->dev, "%s: failed to enable bkops %d\n",
__func__, err);
@@ -5053,7 +5054,7 @@ static int ufshcd_disable_auto_bkops(struct
ufs_hba *hba)
}
err = ufshcd_query_flag_retry(hba, UPIU_QUERY_OPCODE_CLEAR_FLAG,
- QUERY_FLAG_IDN_BKOPS_EN, NULL);
+ QUERY_FLAG_IDN_BKOPS_EN, 0, NULL);
if (err) {
dev_err(hba->dev, "%s: failed to disable bkops %d\n",
__func__, err);
@@ -5219,7 +5220,7 @@ static int ufshcd_wb_ctrl(struct ufs_hba *hba,
bool enable)
opcode = UPIU_QUERY_OPCODE_CLEAR_FLAG;
ret = ufshcd_query_flag_retry(hba, opcode,
- QUERY_FLAG_IDN_WB_EN, NULL);
+ QUERY_FLAG_IDN_WB_EN, 0, NULL);
Re: [RESEND PATCH v5 0/3] BQ25150/155 Charger
Hi, On Fri, May 01, 2020 at 01:09:13PM -0500, Ricardo Rivera-Matos wrote: > On 5/1/20 12:55 PM, Dan Murphy wrote: > > Sebastian > > > > On 5/1/20 12:24 PM, Sebastian Reichel wrote: > > > Hi, > > > > > > I don't see any PATCHv5 (with or without RESEND) for bq25150 and > > > lore does not see anything either: > > > > > > https://lore.kernel.org/linux-pm/?q=PATCH+v5+0%2F3%5D+BQ25150%2F155+Charger > > > > > > > I posted them for Ricardo. Maybe he need a lore account. > > That is most likely the issue. Sorry for the confusion, all. I am setting > one up now. lore.kernel.org picks up any patches send to the mailing list. You don't need an account. So basically the mailing list never received the original v5 and I did not receive the mails directly either. Ricardo, I would have a look at your local git mail setup. Possibly test it with some demo target address under your control first. -- Sebastian > > https://lore.kernel.org/patchwork/project/lkml/list/?series=441577 > > > > Not sure why his patches did not go through. > > > > Dan > > signature.asc Description: PGP signature
Re: [PATCH 4/4] power_supply: Add power supply type property to uevent env
Hi,
On Fri, Apr 24, 2020 at 11:35:33AM -0600, Mathew King wrote:
> Add POWER_SUPPLY_TYPE to the uevent env for power supply. Type is a
> property of all power supplies and there is a sysfs entry for it but it
> is not included in the properties array of the power supply so
> explicitly add it to the udev env.
>
> Signed-off-by: Mathew King
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/power/supply/power_supply_sysfs.c | 61 ++-
> 1 file changed, 37 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/power/supply/power_supply_sysfs.c
> b/drivers/power/supply/power_supply_sysfs.c
> index fbb05466b9a5..c7087cd7ffe3 100644
> --- a/drivers/power/supply/power_supply_sysfs.c
> +++ b/drivers/power/supply/power_supply_sysfs.c
> @@ -448,6 +448,37 @@ void power_supply_destroy_attrs(void)
> }
> }
>
> +static int add_prop_uevent(struct device *dev, struct kobj_uevent_env *env,
> +enum power_supply_property prop, char *prop_buf)
> +{
> + int ret = 0;
> + struct power_supply_attr *pwr_attr;
> + struct device_attribute *dev_attr;
> + char *line;
> +
> + pwr_attr = _supply_attrs[prop];
> + dev_attr = _attr->dev_attr;
> +
> + ret = power_supply_show_property(dev, dev_attr, prop_buf);
> + if (ret == -ENODEV || ret == -ENODATA) {
> + /*
> + * When a battery is absent, we expect -ENODEV. Don't abort;
> + * send the uevent with at least the the PRESENT=0 property
> + */
> + return 0;
> + }
> +
> + if (ret < 0)
> + return ret;
> +
> + line = strchr(prop_buf, '\n');
> + if (line)
> + *line = 0;
> +
> + return add_uevent_var(env, "POWER_SUPPLY_%s=%s",
> + pwr_attr->upper_name, prop_buf);
> +}
> +
> int power_supply_uevent(struct device *dev, struct kobj_uevent_env *env)
> {
> struct power_supply *psy = dev_get_drvdata(dev);
> @@ -467,31 +498,13 @@ int power_supply_uevent(struct device *dev, struct
> kobj_uevent_env *env)
> if (!prop_buf)
> return -ENOMEM;
>
> - for (j = 0; j < psy->desc->num_properties; j++) {
> - struct power_supply_attr *pwr_attr;
> - struct device_attribute *dev_attr;
> - char *line;
> -
> - pwr_attr = _supply_attrs[psy->desc->properties[j]];
> - dev_attr = _attr->dev_attr;
> -
> - ret = power_supply_show_property(dev, dev_attr, prop_buf);
> - if (ret == -ENODEV || ret == -ENODATA) {
> - /* When a battery is absent, we expect -ENODEV. Don't
> abort;
> -send the uevent with at least the the PRESENT=0
> property */
> - ret = 0;
> - continue;
> - }
> -
> - if (ret < 0)
> - goto out;
> -
> - line = strchr(prop_buf, '\n');
> - if (line)
> - *line = 0;
> + ret = add_prop_uevent(dev, env, POWER_SUPPLY_PROP_TYPE, prop_buf);
> + if (ret)
> + goto out;
>
> - ret = add_uevent_var(env, "POWER_SUPPLY_%s=%s",
> - pwr_attr->upper_name, prop_buf);
> + for (j = 0; j < psy->desc->num_properties; j++) {
> + ret = add_prop_uevent(dev, env, psy->desc->properties[j],
> + prop_buf);
> if (ret)
> goto out;
> }
> --
> 2.26.2.303.gf8c07b1a785-goog
>
signature.asc
Description: PGP signature
Re: [PATCH 3/4] power_supply: Add a macro that maps enum properties to text values
Hi,
On Fri, Apr 24, 2020 at 11:35:32AM -0600, Mathew King wrote:
> Reduce the number of touch points to add a new enum property to the
> power_supply class by mapping the array of text values to the device
> attribute descriptor. A new enum property can now added by creating an
> array with the text values named POWER_SUPPLY_${PROPNAME}_TEXT and
> adding POWER_SUPPLY_ENUM_ATTR(${PROPNAME}) to the power_supply_attrs
> array.
>
> Signed-off-by: Mathew King
> ---
nice cleanup :)
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/power/supply/power_supply_sysfs.c | 122 +-
> 1 file changed, 49 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/power/supply/power_supply_sysfs.c
> b/drivers/power/supply/power_supply_sysfs.c
> index 328107589770..fbb05466b9a5 100644
> --- a/drivers/power/supply/power_supply_sysfs.c
> +++ b/drivers/power/supply/power_supply_sysfs.c
> @@ -26,15 +26,25 @@ struct power_supply_attr {
> const char *upper_name;
> const char *lower_name;
> struct device_attribute dev_attr;
> + const char * const *text_values;
> + int text_values_len;
> };
>
> -#define POWER_SUPPLY_ATTR(_name) \
> -[POWER_SUPPLY_PROP_ ## _name] = \
> -{\
> - .prop_name = #_name \
> +#define _POWER_SUPPLY_ATTR(_name, _text, _len) \
> +[POWER_SUPPLY_PROP_ ## _name] = \
> +{\
> + .prop_name = #_name,\
> + .text_values = _text, \
> + .text_values_len = _len,\
> }
>
> -static const char * const power_supply_type_text[] = {
> +#define POWER_SUPPLY_ATTR(_name) _POWER_SUPPLY_ATTR(_name, NULL, 0)
> +#define _POWER_SUPPLY_ENUM_ATTR(_name, _text)\
> + _POWER_SUPPLY_ATTR(_name, _text, ARRAY_SIZE(_text))
> +#define POWER_SUPPLY_ENUM_ATTR(_name)\
> + _POWER_SUPPLY_ENUM_ATTR(_name, POWER_SUPPLY_ ## _name ## _TEXT)
> +
> +static const char * const POWER_SUPPLY_TYPE_TEXT[] = {
> [POWER_SUPPLY_TYPE_UNKNOWN] = "Unknown",
> [POWER_SUPPLY_TYPE_BATTERY] = "Battery",
> [POWER_SUPPLY_TYPE_UPS] = "UPS",
> @@ -62,7 +72,7 @@ static const char * const POWER_SUPPLY_USB_TYPE_TEXT[] = {
> [POWER_SUPPLY_USB_TYPE_APPLE_BRICK_ID] = "BrickID",
> };
>
> -static const char * const power_supply_status_text[] = {
> +static const char * const POWER_SUPPLY_STATUS_TEXT[] = {
> [POWER_SUPPLY_STATUS_UNKNOWN] = "Unknown",
> [POWER_SUPPLY_STATUS_CHARGING] = "Charging",
> [POWER_SUPPLY_STATUS_DISCHARGING] = "Discharging",
> @@ -70,7 +80,7 @@ static const char * const power_supply_status_text[] = {
> [POWER_SUPPLY_STATUS_FULL] = "Full",
> };
>
> -static const char * const power_supply_charge_type_text[] = {
> +static const char * const POWER_SUPPLY_CHARGE_TYPE_TEXT[] = {
> [POWER_SUPPLY_CHARGE_TYPE_UNKNOWN] = "Unknown",
> [POWER_SUPPLY_CHARGE_TYPE_NONE] = "N/A",
> [POWER_SUPPLY_CHARGE_TYPE_TRICKLE] = "Trickle",
> @@ -80,7 +90,7 @@ static const char * const power_supply_charge_type_text[] =
> {
> [POWER_SUPPLY_CHARGE_TYPE_CUSTOM] = "Custom",
> };
>
> -static const char * const power_supply_health_text[] = {
> +static const char * const POWER_SUPPLY_HEALTH_TEXT[] = {
> [POWER_SUPPLY_HEALTH_UNKNOWN] = "Unknown",
> [POWER_SUPPLY_HEALTH_GOOD] = "Good",
> [POWER_SUPPLY_HEALTH_OVERHEAT] = "Overheat",
> @@ -93,7 +103,7 @@ static const char * const power_supply_health_text[] = {
> [POWER_SUPPLY_HEALTH_OVERCURRENT] = "Over current",
> };
>
> -static const char * const power_supply_technology_text[] = {
> +static const char * const POWER_SUPPLY_TECHNOLOGY_TEXT[] = {
> [POWER_SUPPLY_TECHNOLOGY_UNKNOWN] = "Unknown",
> [POWER_SUPPLY_TECHNOLOGY_NiMH] = "NiMH",
> [POWER_SUPPLY_TECHNOLOGY_LION] = "Li-ion",
> @@ -103,7 +113,7 @@ static const char * const power_supply_technology_text[]
> = {
> [POWER_SUPPLY_TECHNOLOGY_LiMn] = "LiMn",
> };
>
> -static const char * const power_supply_capacity_level_text[] = {
> +static const char * const POWER_SUPPLY_CAPACITY_LEVEL_TEXT[] = {
> [POWER_SUPPLY_CAPACITY_LEVEL_UNKNOWN] = "Unknown",
> [POWER_SUPPLY_CAPACITY_LEVEL_CRITICAL] = "Critical",
> [POWER_SUPPLY_CAPACITY_LEVEL_LOW] = "Low",
> @@ -112,7 +122,7 @@ static const char * const
> power_supply_capacity_level_text[] = {
> [POWER_SUPPLY_CAPACITY_LEVEL_FULL] = "Full",
> };
>
> -static const char * const power_supply_scope_text[] = {
> +static const char * const POWER_SUPPLY_SCOPE_TEXT[] = {
> [POWER_SUPPLY_SCOPE_UNKNOWN]= "Unknown",
> [POWER_SUPPLY_SCOPE_SYSTEM] = "System",
> [POWER_SUPPLY_SCOPE_DEVICE] =
Re: [PATCH v5 3/3] power: supply: bq25150 introduce the bq25150
Hi, On Fri, May 01, 2020 at 12:51:18PM -0500, Dan Murphy wrote: > From: Ricardo Rivera-Matos > > Introduce the bq2515x family of chargers. > > Description: > The BQ2515X family of devices are highly integrated battery management > ICs that integrate the most common functions for wearbale devices > namely a charger, an output voltage rail, ADC for battery and system > monitoring, and a push-button controller. > > Datasheets: > bq25150 - http://www.ti.com/lit/ds/symlink/bq25150.pdf > bq25155 - http://www.ti.com/lit/ds/symlink/bq25155.pdf > > Signed-off-by: Ricardo Rivera-Matos > --- > drivers/power/supply/Kconfig |8 + > drivers/power/supply/Makefile |1 + > drivers/power/supply/bq2515x_charger.c | 1170 > 3 files changed, 1179 insertions(+) > create mode 100644 drivers/power/supply/bq2515x_charger.c > > diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig > index f3424fdce341..7732c5586fc2 100644 > --- a/drivers/power/supply/Kconfig > +++ b/drivers/power/supply/Kconfig > @@ -589,6 +589,14 @@ config CHARGER_BQ24735 > help > Say Y to enable support for the TI BQ24735 battery charger. > > +config CHARGER_BQ2515X > + tristate "TI BQ2515X battery charger family" > + depends on I2C > + depends on GPIOLIB || COMPILE_TEST > + select REGMAP_I2C > + help > + Say Y to enable support for the TI BQ2515X battery charger. > + > config CHARGER_BQ25890 > tristate "TI BQ25890 battery charger driver" > depends on I2C > diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile > index 6c7da920ea83..8fcc175a7e22 100644 > --- a/drivers/power/supply/Makefile > +++ b/drivers/power/supply/Makefile > @@ -80,6 +80,7 @@ obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o > obj-$(CONFIG_CHARGER_BQ24190)+= bq24190_charger.o > obj-$(CONFIG_CHARGER_BQ24257)+= bq24257_charger.o > obj-$(CONFIG_CHARGER_BQ24735)+= bq24735-charger.o > +obj-$(CONFIG_CHARGER_BQ2515X)+= bq2515x_charger.o > obj-$(CONFIG_CHARGER_BQ25890)+= bq25890_charger.o > obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o > obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o > diff --git a/drivers/power/supply/bq2515x_charger.c > b/drivers/power/supply/bq2515x_charger.c > new file mode 100644 > index ..c10789235982 > --- /dev/null > +++ b/drivers/power/supply/bq2515x_charger.c > @@ -0,0 +1,1170 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// BQ2515X Battery Charger Driver > +// Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define BQ2515X_MANUFACTURER "Texas Instruments" > + > +#define BQ2515X_STAT00x00 > +#define BQ2515X_STAT10x01 > +#define BQ2515X_STAT20x02 > +#define BQ2515X_FLAG00x03 > +#define BQ2515X_FLAG10x04 > +#define BQ2515X_FLAG20x05 > +#define BQ2515X_FLAG30x06 > +#define BQ2515X_MASK00x07 > +#define BQ2515X_MASK10x08 > +#define BQ2515X_MASK20x09 > +#define BQ2515X_MASK30x0a > +#define BQ2515X_VBAT_CTRL0x12 > +#define BQ2515X_ICHG_CTRL0x13 > +#define BQ2515X_PCHRGCTRL0x14 > +#define BQ2515X_TERMCTRL 0x15 > +#define BQ2515X_BUVLO0x16 > +#define BQ2515X_CHARGERCTRL0 0x17 > +#define BQ2515X_CHARGERCTRL1 0x18 > +#define BQ2515X_ILIMCTRL 0x19 > +#define BQ2515X_LDOCTRL 0x1d > +#define BQ2515X_MRCTRL 0x30 > +#define BQ2515X_ICCTRL0 0x35 > +#define BQ2515X_ICCTRL1 0x36 > +#define BQ2515X_ICCTRL2 0x37 > +#define BQ2515X_ADCCTRL0 0x40 > +#define BQ2515X_ADCCTRL1 0x41 > +#define BQ2515X_ADC_VBAT_M 0x42 > +#define BQ2515X_ADC_VBAT_L 0x43 > +#define BQ2515X_ADC_TS_M 0x44 > +#define BQ2515X_ADC_TS_L 0x45 > +#define BQ2515X_ADC_ICHG_M 0x46 > +#define BQ2515X_ADC_ICHG_L 0x47 > +#define BQ2515X_ADC_ADCIN_M 0x48 > +#define BQ2515X_ADC_ADCIN_L 0x49 > +#define BQ2515X_ADC_VIN_M0x4a > +#define BQ2515X_ADC_VIN_L0x4b > +#define BQ2515X_ADC_PMID_M 0x4c > +#define BQ2515X_ADC_PMID_L 0x4d > +#define BQ2515X_ADC_IIN_M0x4e > +#define BQ2515X_ADC_IIN_L0x4f > +#define BQ2515X_ADC_COMP1_M 0x52 > +#define BQ2515X_ADC_COMP1_L 0X53 > +#define BQ2515X_ADC_COMP2_M 0X54 > +#define BQ2515X_ADC_COMP2_L 0x55 > +#define BQ2515X_ADC_COMP3_M 0x56 > +#define BQ2515X_ADC_COMP3_L 0x57 > +#define BQ2515X_ADC_READ_EN 0x58 > +#define BQ2515X_TS_FASTCHGCTRL 0x61 > +#define BQ2515X_TS_COLD 0x62 > +#define BQ2515X_TS_COOL 0x63 > +#define BQ2515X_TS_WARM 0x64 > +#define BQ2515X_TS_HOT 0x65 > +#define BQ2515X_DEVICE_ID0x6f
Re: [PATCH v29 00/20] Intel SGX foundations
> On May 2, 2020, at 4:05 PM, Dr. Greg wrote: > > On Thu, Apr 30, 2020 at 06:59:11AM +0300, Jarkko Sakkinen wrote: > > Good afternoon, I hope the weekend is going well for everyone. > >>> On Wed, Apr 29, 2020 at 08:14:59AM -0700, Sean Christopherson wrote: >>> On Wed, Apr 29, 2020 at 08:23:29AM +0300, Jarkko Sakkinen wrote: On Sun, Apr 26, 2020 at 11:57:53AM -0500, Dr. Greg wrote: > On Wed, Apr 22, 2020 at 12:52:56AM +0300, Jarkko Sakkinen wrote: >> The current implementation requires that the firmware sets >> IA32_SGXLEPUBKEYHASH* MSRs as writable so that ultimately >> the kernel can decide what enclaves it wants run. The >> implementation does not create any bottlenecks to support >> read-only MSRs later on. > It seems highly unlikely that a driver implementation with any type of > support for read-only launch control registers would ever get into the > kernel. All one needs to do is review the conversations that Matthew > Garrett's lockdown patches engender to get a sense of that, ie: > > https://lwn.net/Articles/818277/ We do not require read-only MSRs. >>> >>> Greg is pointing out the opposite, that supporting read-only MSRs is highly >>> unlikely to ever be supported in the mainline kernel. > >> In a nutshell, what is wrong in the current code changes and what >> *exactly* should we change? This is way too high level at the moment >> at least for my limited brain capacity. > > In a nutshell, the driver needs our patch that implements > cryptographic policy management. > > A patch that: > > 1.) Does not change the default behavior of the driver. > > 2.) Implements capabilities that are consistent with what the hardware > was designed to do, but only at the discretion of the platform owner. > > 3.) Has no impact on the driver architecture. > > The only consumer for this driver are SGX runtimes. To our knowledge, > there exist only two complete runtime implementations, Intel's and > ours. It us unclear why our approach to the use of the technology > should be discriminated against when it doesn't impact the other user > community. Can you clarify how exactly this patch set discriminates against your stack? > > The Linux kernel that I have worked on and supported since 1992 has > always focused on technical rationale and meritocracy rather then > politics. We would be interested in why our proposal for the driver > fails on the former grounds rather then the latter. > >> /Jarkko > > Best wishes for a productive week. > > Dr. Greg > > As always, > Dr. Greg Wettstein, Ph.D, Worker Artisans in autonomously > Enjellic Systems Development, LLC self-defensive IOT platforms > 4206 N. 19th Ave. and edge devices. > Fargo, ND 58102 > PH: 701-281-1686 EMAIL: g...@enjellic.com > -- > "The best way to predict the future is to invent it." >-- Alan Kay
Very Urgent!
Hello Dear Friend, I have Important Matter to Discuss with you concerning my late client died without a Next Of Kin. Send me your private email with your information and kindly indicate your interest by sending me your full data, you will be entitle to 50% 40% for me and 10% to defray all cost, you should be rest assured that this is 100% risk-free also free from any scam/ fraudulent act, Yours Sincerely Mr. Kabiru Wahid
Re: [PATCH v5 2/3] Add the bindings for the bq25150 and bq25155 500mA charging ICs from Texas Instruments.
Hi,
On Fri, May 01, 2020 at 12:51:17PM -0500, Dan Murphy wrote:
> From: Ricardo Rivera-Matos
>
> Description:
> The BQ2515X family of devices are highly integrated battery management
> ICs that integrate the most common functions for wearbale devices
> namely a charger, an output voltage rail, ADC for battery and system
> monitoring, and a push-button controller.
>
> Datasheets:
> http://www.ti.com/lit/ds/symlink/bq25150.pdf
> http://www.ti.com/lit/ds/symlink/bq25155.pdf
>
> CC: Rob Herring
> Signed-off-by: Ricardo Rivera-Matos
> ---
> .../bindings/power/supply/bq2515x.yaml| 99 +++
> 1 file changed, 99 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/power/supply/bq2515x.yaml
>
> diff --git a/Documentation/devicetree/bindings/power/supply/bq2515x.yaml
> b/Documentation/devicetree/bindings/power/supply/bq2515x.yaml
> new file mode 100644
> index ..673caf67a993
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/bq2515x.yaml
> @@ -0,0 +1,99 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (C) 2020 Texas Instruments Incorporated
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/power/supply/bq2515x.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: TI bq2515x 500-mA Linear charger family
> +
> +maintainers:
> + - Dan Murphy
> +
> +description: |
> + The BQ2515x family is a highly integrated battery charge management IC that
> + integrates the most common functions for wearable devices, namely a
> charger,
> + an output voltage rail, ADC for battery and system monitoring, and
> + push-button controller.
> +
> + Specifications about the charger can be found at:
> +http://www.ti.com/lit/ds/symlink/bq25150.pdf
> +http://www.ti.com/lit/ds/symlink/bq25155.pdf
> +
> +properties:
> + compatible:
> +enum:
> + - ti,bq25150
> + - ti,bq25155
> +
> + reg:
> +maxItems: 1
> +
> + ac_detect-gpios:
> +description: |
> + GPIO used for connecting the bq2515x device PG (AC Detect)
> + pin. This pin should be used if possible as this is the
> + recommended way to obtain the charger's input PG state.
> + If this pin is not specified a software-based approach for PG
> + detection is used.
No _ in DT properties, please use ac-detect-gpios as I wrote in PATCHv4.
> + reset-gpios:
> +description: |
> + GPIO used for hardware reset.
> +
> + low-power-gpios:
> +description: |
> + GPIO used for low power mode of IC.
> +
> + charge-enable-gpios:
> +description: |
> + GPIO used to turn on and off charging.
> +
> + constant-charge-current-max-microamp:
> +description: |
> + Maximum charging current in micro Amps.
> +minimum: 5
> +maximum: 60
> +
> + precharge-current-max-microamp:
> +description: |
> + Maximum precharging current in micro Amps.
> +minimum: 1250
> +maximum: 77500
> +
> + input-current-limit-microamp:
> +description: |
> + Maximum input current in micro Amps.
> +minimum: 5
> +maximum: 50
> +
> + constant-charge-voltage-max-microvolt:
> +description: |
> + Maximum charging voltage in micro volts.
> +minimum: 360
> +maximum: 460
The following properties describe battery properties
and should go into a simple-battery node, which is
referenced by the charger. Then you get the properties
in the driver via power_supply_get_battery_info():
constant-charge-current-max-microamp
constant-charge-voltage-max-microvolt
precharge-current-max-microamp
The binding for simple-battery can be found here:
Documentation/devicetree/bindings/power/supply/battery.txt
(still needs to be converted to YAML)
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> +#include
> +i2c0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + charger@6b {
> + compatible = "ti,bq25150";
> + reg = <0x6b>;
> +
> + ac_detect-gpios = < 28 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 14 GPIO_ACTIVE_HIGH>;
> + low-power-gpios = < 15 GPIO_ACTIVE_HIGH>;
> + charge-enable-gpios = < 13 GPIO_ACTIVE_LOW>;
> + constant-charge-current-max-microamp = <30>;
> + constant-charge-voltage-max-microvolt = <420>;
> + precharge-current-max-microamp = <2500>;
> + input-current-limit-microamp = <10>;
bogus indention
> + };
> +};
-- Sebastian
signature.asc
Description: PGP signature
Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()
On Fri, May 1, 2020 at 7:09 AM Luck, Tony wrote: > > > Now maybe copy_to_user() should *always* work this way, but I’m not > > convinced. > > Certainly put_user() shouldn’t — the result wouldn’t even be well defined. > > And I’m > > unconvinced that it makes much sense for the majority of copy_to_user() > > callers > > that are also directly accessing the source structure. > > One case that might work is copy_to_user() that's copying from the kernel > page cache > to the user in response to a read(2) system call. Action would be to check > if we could > re-read from the file system to a different page. If not, return -EIO. Either > way ditch the > poison page from the page cache. > I think that, before we do too much design of the semantics of just the copy function, we need a design for the whole system. Specifically: When the kernel finds out that a kernel page is bad (via #MC or via any other mechanism), what does the kernel do? Does it unmap it? Does it replace it with a dummy page? Does it leave it there? When a copy function hits a bad page and the page is not yet known to be bad, what does it do? (I.e. the page was believed to be fine but the copy function gets #MC.) Does it unmap it right away? What does it return? When a copy function hits a page that is already known to be bad because the kernel got the "oh crap, bad page" notification earlier, what does it do? Return -EIO? Take some fancier action under the assumption that it's called in a preemptible, IRQs-on context, whereas the original #MC or other hardware notification may have come at a less opportune time?
Re: [PATCH v5 1/3] power_supply: Add additional health properties to the header
Hi,
On Fri, May 01, 2020 at 12:51:16PM -0500, Dan Murphy wrote:
> Add HEALTH_WARM, HEALTH_COOL and HEALTH_HOT to the health enum.
>
> Tested-by: Guru Das Srinagesh
> Signed-off-by: Dan Murphy
> ---
What is going on? Ricardo wrote, that he added the JEITA spec
reference to the commit message. I don't see it anywhere. Also
Sandeep Patil asked to be Cc'd in new versions of the patchset.
You do not need to list bq2515x as user, but patch will only be
taken together with the driver (or any other driver using the
properties in mainline kernel).
-- Sebastian
> Documentation/ABI/testing/sysfs-class-power | 2 +-
> drivers/power/supply/power_supply_sysfs.c | 2 +-
> include/linux/power_supply.h| 3 +++
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-power
> b/Documentation/ABI/testing/sysfs-class-power
> index bf3b48f022dc..9f3fd01a9373 100644
> --- a/Documentation/ABI/testing/sysfs-class-power
> +++ b/Documentation/ABI/testing/sysfs-class-power
> @@ -190,7 +190,7 @@ Description:
> Valid values: "Unknown", "Good", "Overheat", "Dead",
> "Over voltage", "Unspecified failure", "Cold",
> "Watchdog timer expire", "Safety timer expire",
> - "Over current"
> + "Over current", "Warm", "Cool", "Hot"
>
> What:/sys/class/power_supply//precharge_current
> Date:June 2017
> diff --git a/drivers/power/supply/power_supply_sysfs.c
> b/drivers/power/supply/power_supply_sysfs.c
> index f37ad4eae60b..d0d549611794 100644
> --- a/drivers/power/supply/power_supply_sysfs.c
> +++ b/drivers/power/supply/power_supply_sysfs.c
> @@ -61,7 +61,7 @@ static const char * const power_supply_charge_type_text[] =
> {
> static const char * const power_supply_health_text[] = {
> "Unknown", "Good", "Overheat", "Dead", "Over voltage",
> "Unspecified failure", "Cold", "Watchdog timer expire",
> - "Safety timer expire", "Over current"
> + "Safety timer expire", "Over current", "Warm", "Cool", "Hot"
> };
>
> static const char * const power_supply_technology_text[] = {
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index dcd5a71e6c67..8670e90c1d51 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -61,6 +61,9 @@ enum {
> POWER_SUPPLY_HEALTH_WATCHDOG_TIMER_EXPIRE,
> POWER_SUPPLY_HEALTH_SAFETY_TIMER_EXPIRE,
> POWER_SUPPLY_HEALTH_OVERCURRENT,
> + POWER_SUPPLY_HEALTH_WARM,
> + POWER_SUPPLY_HEALTH_COOL,
> + POWER_SUPPLY_HEALTH_HOT,
> };
>
> enum {
> --
> 2.25.1
>
signature.asc
Description: PGP signature
Re: [PATCH] power: supply: fix memory leaks (v2)
Hi,
On Sat, May 02, 2020 at 06:33:38PM -0500, wu000...@umn.edu wrote:
> From: Qiushi Wu
>
> In function power_supply_add_hwmon_sysfs(), psyhw->props is
> allocated by bitmap_zalloc(). But this pointer is not deallocated
> when devm_add_action fail, which lead to a memory leak bug. To fix
> this, we replace devm_add_action with devm_add_action_or_reset.
>
> v2:
> - Prevent introducing double-free.
> - Added fixes tag
>
> Fixes: e67d4dfc9ff19 ("power: supply: Add HWMON compatibility layer")
> Signed-off-by: Qiushi Wu
> ---
Thanks, queued to power-supply's for-next branch.
Notes for next time:
* I fixed up the subject, please read how to properly send a v2
* I removed the changelog, it should be below the ---
-- Sebastian
> drivers/power/supply/power_supply_hwmon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/power/supply/power_supply_hwmon.c
> b/drivers/power/supply/power_supply_hwmon.c
> index 75cf861ba492..7c8296ea0c34 100644
> --- a/drivers/power/supply/power_supply_hwmon.c
> +++ b/drivers/power/supply/power_supply_hwmon.c
> @@ -304,7 +304,7 @@ int power_supply_add_hwmon_sysfs(struct power_supply *psy)
> goto error;
> }
>
> - ret = devm_add_action(dev, power_supply_hwmon_bitmap_free,
> + ret = devm_add_action_or_reset(dev, power_supply_hwmon_bitmap_free,
> psyhw->props);
> if (ret)
> goto error;
> --
> 2.17.1
>
signature.asc
Description: PGP signature
[PATCH v4] streamline_config.pl: add LMC_KEEP to preserve some kconfigs
Sometimes it is useful to preserve batches of configs when making
localmodconfig. For example, I usually don't want any usb and fs
modules to be disabled. Now we can do it by:
$ make LMC_KEEP="drivers/usb;fs" localmodconfig
Signed-off-by: Changbin Du
---
v4: fix typo.
v3: rename LOCALMODCONFIG_PRESERVE to shorter LMC_KEEP.
v2: fix typo in documentation. (Randy Dunlap)
---
Documentation/admin-guide/README.rst | 8 +++-
scripts/kconfig/Makefile | 1 +
scripts/kconfig/streamline_config.pl | 23 +++
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/README.rst
b/Documentation/admin-guide/README.rst
index cc6151fc0845..1371deab8bc7 100644
--- a/Documentation/admin-guide/README.rst
+++ b/Documentation/admin-guide/README.rst
@@ -209,10 +209,16 @@ Configuring the kernel
store the lsmod of that machine into a file
and pass it in as a LSMOD parameter.
+ Also, you can preserve modules in certain folders
+ or kconfig files by specifying their paths in
+ parameter LMC_KEEP.
+
target$ lsmod > /tmp/mylsmod
target$ scp /tmp/mylsmod host:/tmp
- host$ make LSMOD=/tmp/mylsmod localmodconfig
+ host$ make LSMOD=/tmp/mylsmod \
+ LMC_KEEP="drivers/usb;drivers/gpu;fs" \
+ localmodconfig
The above also works when cross compiling.
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index c9d0a4a8efb3..e0abbf5805f5 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -123,6 +123,7 @@ help:
@echo ' gconfig - Update current config utilising a GTK+
based front-end'
@echo ' oldconfig - Update current config utilising a provided
.config as base'
@echo ' localmodconfig - Update current config disabling modules not
loaded'
+ @echo 'except those preserved by LMC_KEEP
environment variable'
@echo ' localyesconfig - Update current config converting local mods
to core'
@echo ' defconfig - New config with default from ARCH supplied
defconfig'
@echo ' savedefconfig - Save current config as ./defconfig (minimal
config)'
diff --git a/scripts/kconfig/streamline_config.pl
b/scripts/kconfig/streamline_config.pl
index e2f8504f5a2d..d26543a807c9 100755
--- a/scripts/kconfig/streamline_config.pl
+++ b/scripts/kconfig/streamline_config.pl
@@ -143,6 +143,7 @@ my %depends;
my %selects;
my %prompts;
my %objects;
+my %config2kfile;
my $var;
my $iflevel = 0;
my @ifdeps;
@@ -201,6 +202,7 @@ sub read_kconfig {
if (/^\s*(menu)?config\s+(\S+)\s*$/) {
$state = "NEW";
$config = $2;
+ $config2kfile{"CONFIG_$config"} = $kconfig;
# Add depends for 'if' nesting
for (my $i = 0; $i < $iflevel; $i++) {
@@ -592,6 +594,22 @@ while ($repeat) {
my %setconfigs;
+my @preserved_kconfigs;
+@preserved_kconfigs = split(/;/,$ENV{LMC_KEEP}) if (defined($ENV{LMC_KEEP}));
+
+sub in_preserved_kconfigs {
+my $kconfig = $config2kfile{$_[0]};
+if (!defined($kconfig)) {
+return 0;
+}
+foreach my $excl (@preserved_kconfigs) {
+if($kconfig =~ /^$excl/) {
+return 1;
+}
+}
+return 0;
+}
+
# Finally, read the .config file and turn off any module enabled that
# we could not find a reason to keep enabled.
foreach my $line (@config_file) {
@@ -644,6 +662,11 @@ foreach my $line (@config_file) {
}
if (/^(CONFIG.*)=(m|y)/) {
+if (in_preserved_kconfigs($1)) {
+dprint "Preserve config $1";
+print;
+next;
+}
if (defined($configs{$1})) {
if ($localyesconfig) {
$setconfigs{$1} = 'y';
--
2.25.1
Re: [PATCH v3] streamline_config.pl: add LMC_KEEP to preserve some kconfigs
On Sat, May 02, 2020 at 08:50:22AM -0700, Randy Dunlap wrote:
> On 5/2/20 8:30 AM, Changbin Du wrote:
> > Sometimes it is useful to preserve batches of configs when making
> > localmodconfig. For example, I usually don't want any usb and fs
> > modules to be disabled. Now we can do it by:
> >
> > $ make LMC_KEEP="drivers/usb;fs" localmodconfig
> >
> > Signed-off-by: Changbin Du
> >
> > ---
> > v3: rename LOCALMODCONFIG_PRESERVE to shorter LMC_KEEP.
> > v2: fix typo in documentation. (Randy Dunlap)
> > ---
> > Documentation/admin-guide/README.rst | 8 +++-
> > scripts/kconfig/Makefile | 1 +
> > scripts/kconfig/streamline_config.pl | 23 +++
> > 3 files changed, 31 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/admin-guide/README.rst
> > b/Documentation/admin-guide/README.rst
> > index cc6151fc0845..f7b02ce61ea7 100644
> > --- a/Documentation/admin-guide/README.rst
> > +++ b/Documentation/admin-guide/README.rst
> > @@ -209,10 +209,16 @@ Configuring the kernel
> > store the lsmod of that machine into a file
> > and pass it in as a LSMOD parameter.
> >
> > + Also, you can preserve modules in certain
> > folders
> > + or kconfig files by spcifying their paths in
>
> specifying
>
> More below.
>
Will fix them, thank you!
>
> > + parameter LMC_KEEP.
> > +
> > target$ lsmod > /tmp/mylsmod
> > target$ scp /tmp/mylsmod host:/tmp
> >
> > - host$ make LSMOD=/tmp/mylsmod localmodconfig
> > + host$ make LSMOD=/tmp/mylsmod \
> > + LMC_KEEP="drivers/usb;drivers/gpu;fs" \
> > + localmodconfig
> >
> > The above also works when cross compiling.
> >
> > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> > index c9d0a4a8efb3..e0abbf5805f5 100644
> > --- a/scripts/kconfig/Makefile
> > +++ b/scripts/kconfig/Makefile
> > @@ -123,6 +123,7 @@ help:
> > @echo ' gconfig - Update current config utilising a GTK+
> > based front-end'
> > @echo ' oldconfig - Update current config utilising a provided
> > .config as base'
> > @echo ' localmodconfig - Update current config disabling modules not
> > loaded'
> > + @echo 'except those preserved by LMC_KEEP
> > environment variable'
> > @echo ' localyesconfig - Update current config converting local mods
> > to core'
> > @echo ' defconfig - New config with default from ARCH supplied
> > defconfig'
> > @echo ' savedefconfig - Save current config as ./defconfig (minimal
> > config)'
> > diff --git a/scripts/kconfig/streamline_config.pl
> > b/scripts/kconfig/streamline_config.pl
> > index e2f8504f5a2d..f3a2ceed1e82 100755
> > --- a/scripts/kconfig/streamline_config.pl
> > +++ b/scripts/kconfig/streamline_config.pl
> > @@ -143,6 +143,7 @@ my %depends;
> > my %selects;
> > my %prompts;
> > my %objects;
> > +my %config2kfile;
> > my $var;
> > my $iflevel = 0;
> > my @ifdeps;
> > @@ -201,6 +202,7 @@ sub read_kconfig {
> > if (/^\s*(menu)?config\s+(\S+)\s*$/) {
> > $state = "NEW";
> > $config = $2;
> > + $config2kfile{"CONFIG_$config"} = $kconfig;
> >
> > # Add depends for 'if' nesting
> > for (my $i = 0; $i < $iflevel; $i++) {
> > @@ -592,6 +594,22 @@ while ($repeat) {
> >
> > my %setconfigs;
> >
> > +my @presevered_kconfigs;
>
> s/presevered/preserved/g (g means globally, throughout this script)
>
> > +@presevered_kconfigs = split(/;/,$ENV{LMC_KEEP}) if
> > (defined($ENV{LMC_KEEP}));
> > +
> > +sub in_presevered_kconfigs {
> > +my $kconfig = $config2kfile{$_[0]};
> > +if (!defined($kconfig)) {
> > +return 0;
> > +}
> > +foreach my $excl (@presevered_kconfigs) {
> > +if($kconfig =~ /^$excl/) {
> > +return 1;
> > +}
> > +}
> > +return 0;
> > +}
> > +
> > # Finally, read the .config file and turn off any module enabled that
> > # we could not find a reason to keep enabled.
> > foreach my $line (@config_file) {
> > @@ -644,6 +662,11 @@ foreach my $line (@config_file) {
> > }
> >
> > if (/^(CONFIG.*)=(m|y)/) {
> > +if (in_presevered_kconfigs($1)) {
> > +dprint "Preserve config $1";
> > +print;
> > +next;
> > +}
> > if (defined($configs{$1})) {
> > if ($localyesconfig) {
> > $setconfigs{$1} = 'y';
> >
>
> thanks.
> --
> ~Randy
>
--
Cheers,
Changbin Du
Re: [PATCH v4 2/4] power: supply: core: add input voltage/current measurements
Hi,
On Sun, May 03, 2020 at 01:11:58AM +0200, Michał Mirosław wrote:
> On Sun, May 03, 2020 at 12:45:26AM +0200, Michał Mirosław wrote:
> > On Sun, May 03, 2020 at 12:23:49AM +0200, Sebastian Reichel wrote:
> > > On Fri, May 01, 2020 at 05:11:18PM +0200, Michał Mirosław wrote:
> [...]
> > > > --- a/include/linux/power_supply.h
> > > > +++ b/include/linux/power_supply.h
> > > > @@ -127,7 +127,9 @@ enum power_supply_property {
> > > > POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
> > > > POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD, /* in
> > > > percents! */
> > > > POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD, /* in percents!
> > > > */
> > > > + POWER_SUPPLY_PROP_INPUT_CURRENT_NOW,
> > >
> > > What: /sys/class/power_supply//current_avg
> > > Date: May 2007
> > > Contact:linux...@vger.kernel.org
> > > Description:
> > > Reports an average IBUS current reading over a fixed
> > > period.
> > > Normally devices will provide a fixed interval in which
> > > they
> > > average readings to smooth out the reported value.
> > >
> > >
> > >
> > > Access: Read
> > > Valid values: Represented in microamps
> > >
> >
> > There are two entries for /sys/class/power_supply//current_avg
> > in the file, the other one mentions IBAT instead. "voltage_now" has the
> > same problem.
> [...]
>
> So the general idea of the sysfs API seems to require separate devices for the
> input (charger) and battery elements.
>
> Since what I'm looking at is an integrated battery controller
> (bq25896) which has three connections: an USB power (VBUS), a
> battery and the system load, but it creates only a single
> power-class device.
power-supply exposes either TYPE_MAINS/TYPE_USB or TYPE_BATTERY.
If a device is combined function, then it should register two
power-supply devices.
> This is complicated by the fact that this is an OTG device and so
> it can sink or source VBUS power.
Ok.
-- Sebastian
signature.asc
Description: PGP signature
[PATCH] MIPS: tools: Move "returns" after "loongson3-llsc-check"
Just move "returns" after "loongson3-llsc-check", no function changes. Signed-off-by: Tiezhu Yang --- arch/mips/tools/loongson3-llsc-check.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/tools/loongson3-llsc-check.c b/arch/mips/tools/loongson3-llsc-check.c index facd016..bdbc7b4 100644 --- a/arch/mips/tools/loongson3-llsc-check.c +++ b/arch/mips/tools/loongson3-llsc-check.c @@ -303,7 +303,7 @@ int main(int argc, char *argv[]) out_close: close(vmlinux_fd); out_ret: - fprintf(stdout, "loongson3-llsc-check %s\n", - status ? "returns failure" : "returns success"); + fprintf(stdout, "loongson3-llsc-check returns %s\n", + status ? "failure" : "success"); return status; } -- 2.1.0
Re: [RFC PATCH v11 6/9] media: tegra: Add Tegra210 Video input driver
On 5/2/20 3:46 PM, Sowjanya Komatineni wrote: On 5/2/20 1:48 PM, Dmitry Osipenko wrote: 02.05.2020 19:55, Sowjanya Komatineni пишет: Also stop stream ioctl request happens during suspend where both threads will be stopped properly. done thread stop happens only after finishing all outstanding buffers. Do you mean that V4L core takes care of stopping the streami on suspend and re-starting it on resume from suspend? Stop stream request happens from streaming applications so even without driver suspend/resume implementation currently, streaming will be stopped prior to system suspend where both threads will be stopped properly (after finishing out standing buffers) and will be resumed by application on system resume All userspace is frozen on suspend. System suspension is transparent for userspace applications. I'm not sure what you're meaning here. Also tested suspending while streaming with this unconditional freeze, I don't see any issue as application stops stream where v4l_streamoff gets executed during suspend and on resume streaming starts where v4l_streamon happens. So, I don't see any issue with existing implementation of unconditional freeze. I don't understand why freezing is needed at all if V4L core takes care of stopping the stream on suspend, what is the point? If there is no real point, then let's make threads non-freezable and done with that. video device fops unlocked_ioctl is set to video_ioctl2() in vi driver. video device fops unlocked_ioctl gets executed with stream off cmd during suspend and stream on cmd during resume which eventually calls v4l_streamoff and v4l_streamon during system suspend/resume. My understanding to have freezable threads is during system suspend user space applications are frozen prior to kernel freeze and during suspend when opened video character device node gets closed these ioctl gets invoked and stream off during suspend and stream on during resume happens. So probably we still need to use freezable threads to sync with user space application when frozen before really entering suspend. Will wait for Thierry/Hans comment to correct if my above understanding is wrong and help clarify if we need freezable threads at all in this case... Note: I see other drivers using freezable threads for capture drivers. I see only couple of media drivers using freezable threads. Also, referring to below article probably we don't need freezable threads. https://lwn.net/Articles/662703/ Probably we can then remove thread as freezable... Assuming we use freezable threads, I was saying we don't need conditional try_to_freeze() like you pointed because even if finish thread freeze happens prior to frame capture initiated by start thread, vi hardware will still continue to update this single ongoing buffer and will finish max within 200ms and actually there is no direct processing of this done by finish thread itself except that it returns buffers back when done and in this case it returns back when unfreeze/wake up happens. So, I don't see any issue of unconditional try_to_freeze() even with freezable threads. Thanks Sowjanya
Re: [PATCH v3 04/19] mm: slub: implement SLUB version of obj_to_index()
On Thu, 30 Apr 2020, Roman Gushchin wrote: > Sorry, but what exactly do you mean? I think the right approach is to add a pointer to each slab object for memcg support.
Re: [PATCH] net: usb: qmi_wwan: add support for DW5816e
From: Matt Jolly Date: Sun, 3 May 2020 01:52:28 +1000 > Add support for Dell Wireless 5816e to drivers/net/usb/qmi_wwan.c > > Signed-off-by: Matt Jolly Bjørn, please review.
[PATCH] net: ethernet: ti: Remove TI_CPTS_MOD workaround
My recent commit b6d49cab44b5 ("net: Make PTP-specific drivers depend on
PTP_1588_CLOCK")
exposes a missing dependency in defconfigs that select TI_CPTS without
selecting PTP_1588_CLOCK, leading to linker errors of the form:
drivers/net/ethernet/ti/cpsw.o: in function `cpsw_ndo_stop':
cpsw.c:(.text+0x680): undefined reference to `cpts_unregister'
drivers/net/ethernet/ti/cpsw.o: in function `cpsw_remove':
cpsw.c:(.text+0x81c): undefined reference to `cpts_release'
drivers/net/ethernet/ti/cpsw.o: in function `cpsw_rx_handler':
cpsw.c:(.text+0x1324): undefined reference to `cpts_rx_timestamp'
drivers/net/ethernet/ti/cpsw.o: in function `cpsw_ndo_open':
cpsw.c:(.text+0x15ec): undefined reference to `cpts_register'
drivers/net/ethernet/ti/cpsw.o: in function `cpsw_probe':
cpsw.c:(.text+0x2468): undefined reference to `cpts_release'
That's because TI_CPTS_MOD (which is the symbol gating the _compilation_
of cpts.c) now depends on PTP_1588_CLOCK, and so is not enabled in these
configurations, but TI_CPTS (which is the symbol gating _calls_ to the
cpts functions) _is_ enabled. So we end up compiling calls to functions
that don't exist, resulting in the linker errors.
The reason we have two symbols (TI_CPTS and TI_CPTS_MOD) for the same
driver is due to commit be9ca0d33c85 ("cpsw/netcp: work around reverse
cpts dependency"), which introduced TI_CPTS_MOD because (quoting the
commit message):
> The dependency is reversed: cpsw and netcp call into cpts,
> but cpts depends on the other two in Kconfig. This can lead
> to cpts being a loadable module and its callers built-in:
>
> drivers/net/ethernet/ti/cpsw.o: In function `cpsw_remove':
> cpsw.c:(.text.cpsw_remove+0xd0): undefined reference to `cpts_release'
> drivers/net/ethernet/ti/cpsw.o: In function `cpsw_rx_handler':
> cpsw.c:(.text.cpsw_rx_handler+0x2dc): undefined reference to
> `cpts_rx_timestamp'
> drivers/net/ethernet/ti/cpsw.o: In function `cpsw_tx_handler':
> cpsw.c:(.text.cpsw_tx_handler+0x7c): undefined reference to
> `cpts_tx_timestamp'
> drivers/net/ethernet/ti/cpsw.o: In function `cpsw_ndo_stop':
Both forms of linker error -- those caused by defconfigs that select
TI_CPTS without PTP_1588_CLOCK and those caused by configuring TI_CPSW
as a built-in and TI_CPTS as a module -- can be avoided by using the
IS_REACHABLE() macro to gate calls to cpts functions, and using the
TI_CPTS symbol to gate compilation of cpts.c. cpts.h already provides
the no-op stub implementations of the cpts functions required to make
this work, we just need to change the existing IS_ENABLED(TI_CPTS)
guards to IS_REACHABLE(TI_CPTS).
With this change there is no longer any need for the TI_CPTS_MOD symbol,
so we can remove it.
To preserve the existing behavior of defconfigs that select TI_CPTS, we
must also select PTP_1588_CLOCK so that the dependency is satisfied.
omap2plus_defconfig and keystone_defconfig have not been updated in a
while, so some unrelated no-op changes appear in the diff.
Cc: Arnd Bergmann
Cc: Grygorii Strashko
Fixes: b6d49cab44b5 ("net: Make PTP-specific drivers depend on PTP_1588_CLOCK")
Reported-by: kbuild test robot
Signed-off-by: Clay McClure
---
arch/arm/configs/keystone_defconfig| 72 --
arch/arm/configs/omap2plus_defconfig | 3 +-
drivers/net/ethernet/ti/Kconfig| 13 ++---
drivers/net/ethernet/ti/Makefile | 2 +-
drivers/net/ethernet/ti/cpsw_ethtool.c | 2 +-
drivers/net/ethernet/ti/cpts.h | 3 +-
drivers/net/ethernet/ti/netcp_ethss.c | 10 ++--
7 files changed, 45 insertions(+), 60 deletions(-)
diff --git a/arch/arm/configs/keystone_defconfig
b/arch/arm/configs/keystone_defconfig
index 11e2211f9007..a66c37efa15b 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -1,44 +1,41 @@
# CONFIG_SWAP is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_HIGH_RES_TIMERS=y
+CONFIG_PREEMPT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_CGROUPS=y
+CONFIG_BLK_CGROUP=y
+CONFIG_CGROUP_SCHED=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
-CONFIG_CGROUP_SCHED=y
-CONFIG_BLK_CGROUP=y
CONFIG_BLK_DEV_INITRD=y
-CONFIG_KALLSYMS_ALL=y
# CONFIG_ELF_CORE is not set
# CONFIG_BASE_FULL is not set
+CONFIG_KALLSYMS_ALL=y
CONFIG_EMBEDDED=y
CONFIG_PROFILING=y
-CONFIG_OPROFILE=y
-CONFIG_KPROBES=y
-CONFIG_MODULES=y
-CONFIG_MODULE_FORCE_LOAD=y
-CONFIG_MODULE_UNLOAD=y
-CONFIG_MODULE_FORCE_UNLOAD=y
-CONFIG_MODVERSIONS=y
CONFIG_ARCH_KEYSTONE=y
CONFIG_ARM_LPAE=y
-CONFIG_PCI=y
-CONFIG_PCI_MSI=y
-CONFIG_PCI_KEYSTONE=y
CONFIG_SMP=y
CONFIG_HOTPLUG_CPU=y
CONFIG_ARM_PSCI=y
-CONFIG_PREEMPT=y
-CONFIG_AEABI=y
CONFIG_HIGHMEM=y
-CONFIG_CMA=y
CONFIG_VFP=y
CONFIG_NEON=y
# CONFIG_SUSPEND is not set
CONFIG_PM=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_OPROFILE=y
+CONFIG_KPROBES=y
+CONFIG_MODULES=y
+CONFIG_MODULE_FORCE_LOAD=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+CONFIG_CMA=y
CONFIG_NET=y
Re: [PATCH] stmmac: fix pointer check after utilization in stmmac_interrupt
From: Maxim Petrov Date: Sat, 2 May 2020 12:29:08 +0300 > The paranoidal pointer check in IRQ handler looks very strange - it > really protects us only against bogus drivers which request IRQ line > with null pointer dev_id. However, the code fragment is incorrect > because the dev pointer is used before the actual check. That leads > to undefined behavior thus compilers are free to remove the pointer > check at all. > > Signed-off-by: Maxim Petrov Seriously, just remove this check altogether.
[PATCH] power: supply: fix memory leaks (v2)
From: Qiushi Wu
In function power_supply_add_hwmon_sysfs(), psyhw->props is
allocated by bitmap_zalloc(). But this pointer is not deallocated
when devm_add_action fail, which lead to a memory leak bug. To fix
this, we replace devm_add_action with devm_add_action_or_reset.
v2:
- Prevent introducing double-free.
- Added fixes tag
Fixes: e67d4dfc9ff19 ("power: supply: Add HWMON compatibility layer")
Signed-off-by: Qiushi Wu
---
drivers/power/supply/power_supply_hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/supply/power_supply_hwmon.c
b/drivers/power/supply/power_supply_hwmon.c
index 75cf861ba492..7c8296ea0c34 100644
--- a/drivers/power/supply/power_supply_hwmon.c
+++ b/drivers/power/supply/power_supply_hwmon.c
@@ -304,7 +304,7 @@ int power_supply_add_hwmon_sysfs(struct power_supply *psy)
goto error;
}
- ret = devm_add_action(dev, power_supply_hwmon_bitmap_free,
+ ret = devm_add_action_or_reset(dev, power_supply_hwmon_bitmap_free,
psyhw->props);
if (ret)
goto error;
--
2.17.1
Re: [PATCH v2 net-next 0/3] ptp: Add adjust phase to support phase offset.
From: Date: Fri, 1 May 2020 23:35:35 -0400 > From: Vincent Cheng > > This series adds adjust phase to the PTP Hardware Clock device interface. > > Some PTP hardware clocks have a write phase mode that has > a built-in hardware filtering capability. The write phase mode > utilizes a phase offset control word instead of a frequency offset > control word. Add adjust phase function to take advantage of this > capability. > > Changes since v1: > - As suggested by Richard Cochran: > 1. ops->adjphase is new so need to check for non-null function pointer. > 2. Kernel coding style uses lower_case_underscores. > 3. Use existing PTP clock API for delayed worker. Series applied.
Re: [PATCH 4.4 00/70] 4.4.221-rc1 review
On 5/1/20 7:20 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.221 release. There are 70 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun, 03 May 2020 13:12:02 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.221-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH v4 4/4] gpio: xilinx: Utilize for_each_set_clump macro
On Sat, May 02, 2020 at 03:03:54PM -0400, William Breathitt Gray wrote:
> On Sun, May 03, 2020 at 12:21:54AM +0530, Syed Nayyar Waris wrote:
> > This patch reimplements the xgpio_set_multiple function in
> > drivers/gpio/gpio-xilinx.c to use the new for_each_set_clump macro.
> > Instead of looping for each bit in xgpio_set_multiple
> > function, now we can check each channel at a time and save cycles.
> >
> > Cc: Linus Walleij
> > Cc: Bartosz Golaszewski
> > Cc: Michal Simek
> > Signed-off-by: Syed Nayyar Waris
> > Signed-off-by: William Breathitt Gray
> > ---
> > Changes in v4:
> > - Minor change: Hardcode value for better code readability.
> >
> > Changes in v3:
> > - No change.
> >
> > Changes in v2:
> > - No change.
> >
> > drivers/gpio/gpio-xilinx.c | 64 --
> > 1 file changed, 34 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> > index 67f9f82e0db0..67c5eeaf1bb9 100644
> > --- a/drivers/gpio/gpio-xilinx.c
> > +++ b/drivers/gpio/gpio-xilinx.c
> > @@ -136,39 +136,43 @@ static void xgpio_set(struct gpio_chip *gc, unsigned
> > int gpio, int val)
> > static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
> >unsigned long *bits)
> > {
> > - unsigned long flags;
> > + unsigned long flags[2];
> > struct xgpio_instance *chip = gpiochip_get_data(gc);
> > - int index = xgpio_index(chip, 0);
> > - int offset, i;
> > -
> > - spin_lock_irqsave(>gpio_lock[index], flags);
> > -
> > - /* Write to GPIO signals */
> > - for (i = 0; i < gc->ngpio; i++) {
> > - if (*mask == 0)
> > - break;
> > - /* Once finished with an index write it out to the register */
> > - if (index != xgpio_index(chip, i)) {
> > - xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> > - index * XGPIO_CHANNEL_OFFSET,
> > - chip->gpio_state[index]);
> > - spin_unlock_irqrestore(>gpio_lock[index], flags);
> > - index = xgpio_index(chip, i);
> > - spin_lock_irqsave(>gpio_lock[index], flags);
> > - }
> > - if (__test_and_clear_bit(i, mask)) {
> > - offset = xgpio_offset(chip, i);
> > - if (test_bit(i, bits))
> > - chip->gpio_state[index] |= BIT(offset);
> > - else
> > - chip->gpio_state[index] &= ~BIT(offset);
> > - }
> > + u32 *const state = chip->gpio_state;
> > + unsigned int *const width = chip->gpio_width;
> > + const unsigned long state_size = 32;
> > + const unsigned long total_state_bits = state_size * 2;
>
> Hello Syed,
>
> I don't think there's much need for these two variables either. You can
> remove the state_size and total_state_bits variables, and instead inline
> 32 and 64 directly in your code below.
Hi. Have sent v5 patchset incorporating your review comment.
Thank you.
>
> William Breathitt Gray
>
> > + unsigned long offset, clump;
> > + size_t index;
> > +
> > + DECLARE_BITMAP(old, 64);
> > + DECLARE_BITMAP(new, 64);
> > + DECLARE_BITMAP(changed, 64);
> > +
> > + spin_lock_irqsave(>gpio_lock[0], flags[0]);
> > + spin_lock_irqsave(>gpio_lock[1], flags[1]);
> > +
> > + bitmap_set_value(old, state[0], 0, width[0]);
> > + bitmap_set_value(old, state[1], width[0], width[1]);
> > + bitmap_replace(new, old, bits, mask, gc->ngpio);
> > +
> > + bitmap_set_value(old, state[0], 0, state_size);
> > + bitmap_set_value(old, state[1], state_size, state_size);
> > + state[0] = bitmap_get_value(new, 0, width[0]);
> > + state[1] = bitmap_get_value(new, width[0], width[1]);
> > + bitmap_set_value(new, state[0], 0, state_size);
> > + bitmap_set_value(new, state[1], state_size, state_size);
> > + bitmap_xor(changed, old, new, total_state_bits);
> > +
> > + for_each_set_clump(offset, clump, changed, total_state_bits,
> > state_size) {
> > + index = offset / state_size;
> > + xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> > + index * XGPIO_CHANNEL_OFFSET,
> > + state[index]);
> > }
> >
> > - xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> > - index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]);
> > -
> > - spin_unlock_irqrestore(>gpio_lock[index], flags);
> > + spin_unlock_irqrestore(>gpio_lock[1], flags[1]);
> > + spin_unlock_irqrestore(>gpio_lock[0], flags[0]);
> > }
> >
> > /**
> > --
> > 2.26.2
> >
[PATCH v5 4/4] gpio: xilinx: Utilize for_each_set_clump macro
This patch reimplements the xgpio_set_multiple function in
drivers/gpio/gpio-xilinx.c to use the new for_each_set_clump macro.
Instead of looping for each bit in xgpio_set_multiple
function, now we can check each channel at a time and save cycles.
Cc: Linus Walleij
Cc: Bartosz Golaszewski
Cc: Michal Simek
Signed-off-by: Syed Nayyar Waris
Signed-off-by: William Breathitt Gray
---
Changes in v5:
- Minor change: Inline values '32' and '64' in code for better
code readability.
Changes in v4:
- Minor change: Inline values '32' and '64' in code for better
code readability.
Changes in v3:
- No change.
Changes in v2:
- No change.
drivers/gpio/gpio-xilinx.c | 62 --
1 file changed, 32 insertions(+), 30 deletions(-)
diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index 67f9f82e0db0..e81092dea27e 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -136,39 +136,41 @@ static void xgpio_set(struct gpio_chip *gc, unsigned int
gpio, int val)
static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
unsigned long *bits)
{
- unsigned long flags;
+ unsigned long flags[2];
struct xgpio_instance *chip = gpiochip_get_data(gc);
- int index = xgpio_index(chip, 0);
- int offset, i;
-
- spin_lock_irqsave(>gpio_lock[index], flags);
-
- /* Write to GPIO signals */
- for (i = 0; i < gc->ngpio; i++) {
- if (*mask == 0)
- break;
- /* Once finished with an index write it out to the register */
- if (index != xgpio_index(chip, i)) {
- xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
- index * XGPIO_CHANNEL_OFFSET,
- chip->gpio_state[index]);
- spin_unlock_irqrestore(>gpio_lock[index], flags);
- index = xgpio_index(chip, i);
- spin_lock_irqsave(>gpio_lock[index], flags);
- }
- if (__test_and_clear_bit(i, mask)) {
- offset = xgpio_offset(chip, i);
- if (test_bit(i, bits))
- chip->gpio_state[index] |= BIT(offset);
- else
- chip->gpio_state[index] &= ~BIT(offset);
- }
+ u32 *const state = chip->gpio_state;
+ unsigned int *const width = chip->gpio_width;
+ unsigned long offset, clump;
+ size_t index;
+
+ DECLARE_BITMAP(old, 64);
+ DECLARE_BITMAP(new, 64);
+ DECLARE_BITMAP(changed, 64);
+
+ spin_lock_irqsave(>gpio_lock[0], flags[0]);
+ spin_lock_irqsave(>gpio_lock[1], flags[1]);
+
+ bitmap_set_value(old, state[0], 0, width[0]);
+ bitmap_set_value(old, state[1], width[0], width[1]);
+ bitmap_replace(new, old, bits, mask, gc->ngpio);
+
+ bitmap_set_value(old, state[0], 0, 32);
+ bitmap_set_value(old, state[1], 32, 32);
+ state[0] = bitmap_get_value(new, 0, width[0]);
+ state[1] = bitmap_get_value(new, width[0], width[1]);
+ bitmap_set_value(new, state[0], 0, 32);
+ bitmap_set_value(new, state[1], 32, 32);
+ bitmap_xor(changed, old, new, 64);
+
+ for_each_set_clump(offset, clump, changed, 64, 32) {
+ index = offset / 32;
+ xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
+ index * XGPIO_CHANNEL_OFFSET,
+ state[index]);
}
- xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
- index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]);
-
- spin_unlock_irqrestore(>gpio_lock[index], flags);
+ spin_unlock_irqrestore(>gpio_lock[1], flags[1]);
+ spin_unlock_irqrestore(>gpio_lock[0], flags[0]);
}
/**
--
2.26.2
Re: [PATCH 4.14 000/117] 4.14.178-rc1 review
On 5/1/20 7:20 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.178 release. There are 117 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun, 03 May 2020 13:12:02 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.178-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.9 00/80] 4.9.221-rc1 review
On 5/1/20 7:20 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.221 release. There are 80 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun, 03 May 2020 13:12:02 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.221-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
[PATCH v5 3/4] gpio: thunderx: Utilize for_each_set_clump macro
This patch reimplements the thunderx_gpio_set_multiple function in
drivers/gpio/gpio-thunderx.c to use the new for_each_set_clump macro.
Instead of looping for each bank in thunderx_gpio_set_multiple
function, now we can skip bank which is not set and save cycles.
Cc: Robert Richter
Cc: Linus Walleij
Cc: Bartosz Golaszewski
Signed-off-by: Syed Nayyar Waris
Signed-off-by: William Breathitt Gray
---
Changes in v5:
- No change.
Changes in v4:
- Minor change: Inline value '64' in code for better code readability.
Changes in v3:
- Change datatype of some variables from u64 to unsigned long
in function thunderx_gpio_set_multiple.
CHanges in v2:
- No change.
drivers/gpio/gpio-thunderx.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-thunderx.c b/drivers/gpio/gpio-thunderx.c
index 9f66deab46ea..58c9bb25a377 100644
--- a/drivers/gpio/gpio-thunderx.c
+++ b/drivers/gpio/gpio-thunderx.c
@@ -275,12 +275,15 @@ static void thunderx_gpio_set_multiple(struct gpio_chip
*chip,
unsigned long *bits)
{
int bank;
- u64 set_bits, clear_bits;
+ unsigned long set_bits, clear_bits, gpio_mask;
+ unsigned long offset;
+
struct thunderx_gpio *txgpio = gpiochip_get_data(chip);
- for (bank = 0; bank <= chip->ngpio / 64; bank++) {
- set_bits = bits[bank] & mask[bank];
- clear_bits = ~bits[bank] & mask[bank];
+ for_each_set_clump(offset, gpio_mask, mask, chip->ngpio, 64) {
+ bank = offset / 64;
+ set_bits = bits[bank] & gpio_mask;
+ clear_bits = ~bits[bank] & gpio_mask;
writeq(set_bits, txgpio->register_base + (bank * GPIO_2ND_BANK)
+ GPIO_TX_SET);
writeq(clear_bits, txgpio->register_base + (bank *
GPIO_2ND_BANK) + GPIO_TX_CLR);
}
--
2.26.2
Re: [PATCH 4.19 00/46] 4.19.120-rc1 review
On 5/1/20 7:22 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.19.120 release. There are 46 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun, 03 May 2020 13:12:02 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.120-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH] mm: slub: add panic_on_error to the debug facilities
On Fri, 1 May 2020, Rafael Aquini wrote: > Sometimes it is desirable to override SLUB's debug facilities > default behavior upon stumbling on a cache or object error > and just stop the execution in order to grab a coredump, at > the error-spotting time, instead of trying to fix the issue > and report in an attempt to keep the system rolling. The stopping of execution on an error is the default behavior. Usually you get some OOPS somewhere when data is corrupted and that causes a core dump. SLUB can fix the issue and continue if enabled by specifying special options on boot. That is *not* the default.
Re: [PATCH 5.4 00/83] 5.4.37-rc1 review
On 5/1/20 7:22 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 5.4.37 release. There are 83 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun, 03 May 2020 13:12:02 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.37-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 5.6 000/106] 5.6.9-rc1 review
On 5/1/20 7:22 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 5.6.9 release. There are 106 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun, 03 May 2020 13:12:02 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.9-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.6.y and the diffstat can be found below. thanks, greg k-h - Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH v4 2/4] power: supply: core: add input voltage/current measurements
On Sun, May 03, 2020 at 12:45:26AM +0200, Michał Mirosław wrote:
> On Sun, May 03, 2020 at 12:23:49AM +0200, Sebastian Reichel wrote:
> > On Fri, May 01, 2020 at 05:11:18PM +0200, Michał Mirosław wrote:
[...]
> > > --- a/include/linux/power_supply.h
> > > +++ b/include/linux/power_supply.h
> > > @@ -127,7 +127,9 @@ enum power_supply_property {
> > > POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
> > > POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD, /* in percents! */
> > > POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD, /* in percents! */
> > > + POWER_SUPPLY_PROP_INPUT_CURRENT_NOW,
> >
> > What: /sys/class/power_supply//current_avg
> > Date: May 2007
> > Contact:linux...@vger.kernel.org
> > Description:
> > Reports an average IBUS current reading over a fixed
> > period.
> > Normally devices will provide a fixed interval in which
> > they
> > average readings to smooth out the reported value.
> >
> >
> >
> > Access: Read
> > Valid values: Represented in microamps
> >
>
> There are two entries for /sys/class/power_supply//current_avg
> in the file, the other one mentions IBAT instead. "voltage_now" has the
> same problem.
[...]
So the general idea of the sysfs API seems to require separate devices for the
input (charger) and battery elements. Since what I'm looking at is an
integrated battery controller (bq25896) which has three connections: an USB
power (VBUS), a battery and the system load, but it creates only a single
power-class device. This is complicated by the fact that this is an OTG device
and so it can sink or source VBUS power.
Best Regards,
Michał Mirosław
[PATCH v5 2/4] lib/test_bitmap.c: Add for_each_set_clump test cases
The introduction of the generic for_each_set_clump macro need test
cases to verify the implementation. This patch adds test cases for
scenarios in which clump sizes are 8 bits, 24 bits, 30 bits and 6 bits.
The cases contain situations where clump is getting split at the word
boundary and also when zeroes are present in the start and middle of
bitmap.
Cc: Andy Shevchenko
Cc: Linus Walleij
Signed-off-by: Syed Nayyar Waris
Signed-off-by: William Breathitt Gray
---
Changes in v5:
- No change.
Changes in v4:
- Use 'for' loop in test function of 'for_each_set_clump'.
Changes in v3:
- No Change.
Changes in v2:
- Unify different tests for 'for_each_set_clump'. Pass test data as
function parameters.
- Remove unnecessary bitmap_zero calls.
lib/test_bitmap.c | 141 ++
1 file changed, 141 insertions(+)
diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index 6b13150667f5..a2a1c411dd62 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -155,6 +155,38 @@ static bool __init __check_eq_clump8(const char *srcfile,
unsigned int line,
return true;
}
+static bool __init __check_eq_clump(const char *srcfile, unsigned int line,
+ const unsigned int offset,
+ const unsigned int size,
+ const unsigned long *const clump_exp,
+ const unsigned long *const clump,
+ const unsigned long clump_size)
+{
+ unsigned long exp;
+
+ if (offset >= size) {
+ pr_warn("[%s:%u] bit offset for clump out-of-bounds: expected
less than %u, got %u\n",
+ srcfile, line, size, offset);
+ return false;
+ }
+
+ exp = clump_exp[offset / clump_size];
+ if (!exp) {
+ pr_warn("[%s:%u] bit offset for zero clump: expected nonzero
clump, got bit offset %u with clump value 0",
+ srcfile, line, offset);
+ return false;
+ }
+
+ if (*clump != exp) {
+ pr_warn("[%s:%u] expected clump value of 0x%lX, got clump value
of 0x%lX",
+ srcfile, line, exp, *clump);
+ return false;
+ }
+
+ return true;
+}
+
+
#define __expect_eq(suffix, ...) \
({ \
int result = 0; \
@@ -172,6 +204,7 @@ static bool __init __check_eq_clump8(const char *srcfile,
unsigned int line,
#define expect_eq_pbl(...) __expect_eq(pbl, ##__VA_ARGS__)
#define expect_eq_u32_array(...) __expect_eq(u32_array, ##__VA_ARGS__)
#define expect_eq_clump8(...) __expect_eq(clump8, ##__VA_ARGS__)
+#define expect_eq_clump(...) __expect_eq(clump, ##__VA_ARGS__)
static void __init test_zero_clear(void)
{
@@ -588,6 +621,71 @@ static const unsigned char clump_exp[] __initconst = {
0x05, /* non-adjacent 2 bits set */
};
+static const unsigned long bitmap_test_data[] __initconst = {
+ 0x38000201,
+ 0x05ff0f38,
+ 0xeffedcba,
+ 0xabcd,
+ 0x00aa,
+ 0x00aa,
+ 0x00ff,
+ 0xaa00,
+ 0xff00,
+ 0x00aa,
+ 0x,
+ 0x,
+ 0x,
+ 0x0f00,
+ 0x0ac0,
+};
+
+static const unsigned long clump_exp1[] __initconst = {
+ 0x01, /* 1 bit set */
+ 0x02, /* non-edge 1 bit set */
+ 0x00, /* zero bits set */
+ 0x38, /* 3 bits set across 4-bit boundary */
+ 0x38, /* Repeated clump */
+ 0x0F, /* 4 bits set */
+ 0xFF, /* all bits set */
+ 0x05, /* non-adjacent 2 bits set */
+};
+
+static const unsigned long clump_exp2[] __initconst = {
+ 0xfedcba, /* 24 bits */
+ 0xabcdef,
+ 0xaa, /* Clump split between 2 words */
+ 0x00, /* zeroes in between */
+ 0xaa,
+ 0x00,
+ 0xff,
+ 0xaa,
+ 0x00,
+ 0xff,
+};
+
+static const unsigned long clump_exp3[] __initconst = {
+ 0x, /* starting with 0s*/
+ 0x, /* All 0s */
+ 0x,
+ 0x,
+ 0x3f0f, /* Non zero set */
+ 0x2aa80003,
+ 0x0aaa,
+ 0x3fc0,
+};
+
+static const unsigned long clump_exp4[] __initconst = {
+ 0x00,
+ 0x2b,
+};
+
+static const unsigned long * const clump_data[] __initconst = {
+ clump_exp1,
+ clump_exp2,
+ clump_exp3,
+ clump_exp4,
+};
+
static void __init test_for_each_set_clump8(void)
{
#define CLUMP_EXP_NUMBITS 64
@@ -610,6 +708,48 @@ static void __init test_for_each_set_clump8(void)
expect_eq_clump8(start, CLUMP_EXP_NUMBITS, clump_exp, );
}
+static void __init
[PATCH v5 1/4] bitops: Introduce the the for_each_set_clump macro
This macro iterates for each group of bits (clump) with set bits,
within a bitmap memory region. For each iteration, "start" is set to
the bit offset of the found clump, while the respective clump value is
stored to the location pointed by "clump". Additionally, the
bitmap_get_value and bitmap_set_value functions are introduced to
respectively get and set a value of n-bits in a bitmap memory region.
The n-bits can have any size less than or equal to BITS_PER_LONG.
Moreover, during setting value of n-bit in bitmap, if a situation arise
that the width of next n-bit is exceeding the word boundary, then it
will divide itself such that some portion of it is stored in that word,
while the remaining portion is stored in the next higher word. Similar
situation occurs while retrieving value of n-bits from bitmap.
Cc: Arnd Bergmann
Signed-off-by: Syed Nayyar Waris
Signed-off-by: William Breathitt Gray
---
Changes in v5:
- No change.
Changes in v4:
- No change
Changes in v3:
- No change
Changes in v2:
- No change
include/asm-generic/bitops/find.h | 19 ++
include/linux/bitmap.h| 61 +++
include/linux/bitops.h| 13 +++
lib/find_bit.c| 14 +++
4 files changed, 107 insertions(+)
diff --git a/include/asm-generic/bitops/find.h
b/include/asm-generic/bitops/find.h
index 9fdf21302fdf..4e6600759455 100644
--- a/include/asm-generic/bitops/find.h
+++ b/include/asm-generic/bitops/find.h
@@ -97,4 +97,23 @@ extern unsigned long find_next_clump8(unsigned long *clump,
#define find_first_clump8(clump, bits, size) \
find_next_clump8((clump), (bits), (size), 0)
+/**
+ * find_next_clump - find next clump with set bits in a memory region
+ * @clump: location to store copy of found clump
+ * @addr: address to base the search on
+ * @size: bitmap size in number of bits
+ * @offset: bit offset at which to start searching
+ * @clump_size: clump size in bits
+ *
+ * Returns the bit offset for the next set clump; the found clump value is
+ * copied to the location pointed by @clump. If no bits are set, returns @size.
+ */
+extern unsigned long find_next_clump(unsigned long *clump,
+ const unsigned long *addr,
+ unsigned long size, unsigned long offset,
+ unsigned long clump_size);
+
+#define find_first_clump(clump, bits, size, clump_size) \
+ find_next_clump((clump), (bits), (size), 0, (clump_size))
+
#endif /*_ASM_GENERIC_BITOPS_FIND_H_ */
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 99058eb81042..7ab2c65fc964 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -75,7 +75,11 @@
* bitmap_from_arr32(dst, buf, nbits) Copy nbits from u32[] buf to
dst
* bitmap_to_arr32(buf, src, nbits)Copy nbits from buf to u32[]
dst
* bitmap_get_value8(map, start) Get 8bit value from map at
start
+ * bitmap_get_value(map, start, nbits)Get bit value of size
+ * 'nbits' from map at start
* bitmap_set_value8(map, value, start)Set 8bit value to map at start
+ * bitmap_set_value(map, value, start, nbits) Set bit value of size 'nbits'
+ * of map at start
*
* Note, bitmap_zero() and bitmap_fill() operate over the region of
* unsigned longs, that is, bits behind bitmap till the unsigned long
@@ -563,6 +567,34 @@ static inline unsigned long bitmap_get_value8(const
unsigned long *map,
return (map[index] >> offset) & 0xFF;
}
+/**
+ * bitmap_get_value - get a value of n-bits from the memory region
+ * @map: address to the bitmap memory region
+ * @start: bit offset of the n-bit value
+ * @nbits: size of value in bits
+ *
+ * Returns value of nbits located at the @start bit offset within the @map
+ * memory region.
+ */
+static inline unsigned long bitmap_get_value(const unsigned long *map,
+ unsigned long start,
+ unsigned long nbits)
+{
+ const size_t index = BIT_WORD(start);
+ const unsigned long offset = start % BITS_PER_LONG;
+ const unsigned long ceiling = roundup(start + 1, BITS_PER_LONG);
+ const unsigned long space = ceiling - start;
+ unsigned long value_low, value_high;
+
+ if (space >= nbits)
+ return (map[index] >> offset) & GENMASK(nbits - 1, 0);
+ else {
+ value_low = map[index] & BITMAP_FIRST_WORD_MASK(start);
+ value_high = map[index + 1] & BITMAP_LAST_WORD_MASK(start +
nbits);
+ return (value_low >> offset) | (value_high << space);
+ }
+}
+
/**
* bitmap_set_value8 - set an 8-bit value within a memory region
* @map: address to the bitmap memory region
@@ -579,6 +611,35 @@ static inline void bitmap_set_value8(unsigned long
[PATCH v5 0/4] Introduce the for_each_set_clump macro
This patchset introduces a new generic version of for_each_set_clump. The previous version of for_each_set_clump8 used a fixed size 8-bit clump, but the new generic version can work with clump of any size but less than or equal to BITS_PER_LONG. The patchset utilizes the new macro in several GPIO drivers. The earlier 8-bit for_each_set_clump8 facilitated a for-loop syntax that iterates over a memory region entire groups of set bits at a time. For example, suppose you would like to iterate over a 32-bit integer 8 bits at a time, skipping over 8-bit groups with no set bit, where represents the current 8-bit group: Example:1010 00110011 First loop: 1010 Second loop:1010 00110011 Third loop: 00110011 Each iteration of the loop returns the next 8-bit group that has at least one set bit. But with the new for_each_set_clump the clump size can be different from 8 bits. Moreover, the clump can be split at word boundary in situations where word size is not multiple of clump size. Following are examples showing the working of new macro for clump sizes of 24 bits and 6 bits. Example 1: clump size: 24 bits, Number of clumps (or ports): 10 bitmap stores the bit information from where successive clumps are retrieved. /* bitmap memory region */ 0x00aaff00; /* Most significant bits */ 0xaaff; 0x00aa00aa; 0xabcdeffedcba; /* Least significant bits */ Different iterations of for_each_set_clump:- 'offset' is the bit position and 'clump' is the 24 bit clump from the above bitmap. Iteration first:offset: 0 clump: 0xfedcba Iteration second: offset: 24 clump: 0xabcdef Iteration third:offset: 48 clump: 0xaa Iteration fourth: offset: 96 clump: 0xaa Iteration fifth:offset: 144 clump: 0xff Iteration sixth:offset: 168 clump: 0xaa Iteration seventh: offset: 216 clump: 0xff Loop breaks because in the end the remaining bits (0x00aa) size was less than clump size of 24 bits. In above example it can be seen that in iteration third, the 24 bit clump that was retrieved was split between bitmap[0] and bitmap[1]. This example also shows that 24 bit zeroes if present in between, were skipped (preserving the previous for_each_set_macro8 behaviour). Example 2: clump size = 6 bits, Number of clumps (or ports) = 3. /* bitmap memory region */ 0x00aaff00; /* Most significant bits */ 0xaaff; 0x0f00; 0x0ac0; /* Least significant bits */ Different iterations of for_each_set_clump: 'offset' is the bit position and 'clump' is the 6 bit clump from the above bitmap. Iteration first:offset: 6 clump: 0x2b Loop breaks because 6 * 3 = 18 bits traversed in bitmap. Here 6 * 3 is clump size * no. of clumps. Changes in v5: - [Patch 4/4]: Minor change: Hardcode value for better code readability. Changes in v4: - [Patch 2/4]: Use 'for' loop in test function of for_each_set_clump. - [Patch 3/4]: Minor change: Hardcode value for better code readability. - [Patch 4/4]: Minor change: Hardcode value for better code readability. Changes in v3: - [Patch 3/4]: Change datatype of some variables from u64 to unsigned long in function thunderx_gpio_set_multiple. CHanges in v2: - [Patch 2/4]: Unify different tests for 'for_each_set_clump'. Pass test data as function parameters. - [Patch 2/4]: Remove unnecessary bitmap_zero calls. Syed Nayyar Waris (4): bitops: Introduce the the for_each_set_clump macro lib/test_bitmap.c: Add for_each_set_clump test cases gpio: thunderx: Utilize for_each_set_clump macro gpio: xilinx: Utilize for_each_set_clump macro drivers/gpio/gpio-thunderx.c | 11 ++- drivers/gpio/gpio-xilinx.c| 62 ++--- include/asm-generic/bitops/find.h | 19 include/linux/bitmap.h| 61 + include/linux/bitops.h| 13 +++ lib/find_bit.c| 14 +++ lib/test_bitmap.c | 141 ++ 7 files changed, 287 insertions(+), 34 deletions(-) base-commit: 25c04a75f14fdc074d7dd1d6d40b49eddd0e66e7 -- 2.26.2
Re: [PATCH v29 00/20] Intel SGX foundations
On Thu, Apr 30, 2020 at 06:59:11AM +0300, Jarkko Sakkinen wrote: Good afternoon, I hope the weekend is going well for everyone. > On Wed, Apr 29, 2020 at 08:14:59AM -0700, Sean Christopherson wrote: > > On Wed, Apr 29, 2020 at 08:23:29AM +0300, Jarkko Sakkinen wrote: > > > On Sun, Apr 26, 2020 at 11:57:53AM -0500, Dr. Greg wrote: > > > > On Wed, Apr 22, 2020 at 12:52:56AM +0300, Jarkko Sakkinen wrote: > > > > > > > > The current implementation requires that the firmware sets > > > > > IA32_SGXLEPUBKEYHASH* MSRs as writable so that ultimately > > > > > the kernel can decide what enclaves it wants run. The > > > > > implementation does not create any bottlenecks to support > > > > > read-only MSRs later on. > > > > > > > It seems highly unlikely that a driver implementation with any type of > > > > support for read-only launch control registers would ever get into the > > > > kernel. All one needs to do is review the conversations that Matthew > > > > Garrett's lockdown patches engender to get a sense of that, ie: > > > > > > > > https://lwn.net/Articles/818277/ > > > > > > We do not require read-only MSRs. > > > > Greg is pointing out the opposite, that supporting read-only MSRs is highly > > unlikely to ever be supported in the mainline kernel. > In a nutshell, what is wrong in the current code changes and what > *exactly* should we change? This is way too high level at the moment > at least for my limited brain capacity. In a nutshell, the driver needs our patch that implements cryptographic policy management. A patch that: 1.) Does not change the default behavior of the driver. 2.) Implements capabilities that are consistent with what the hardware was designed to do, but only at the discretion of the platform owner. 3.) Has no impact on the driver architecture. The only consumer for this driver are SGX runtimes. To our knowledge, there exist only two complete runtime implementations, Intel's and ours. It us unclear why our approach to the use of the technology should be discriminated against when it doesn't impact the other user community. The Linux kernel that I have worked on and supported since 1992 has always focused on technical rationale and meritocracy rather then politics. We would be interested in why our proposal for the driver fails on the former grounds rather then the latter. > /Jarkko Best wishes for a productive week. Dr. Greg As always, Dr. Greg Wettstein, Ph.D, Worker Artisans in autonomously Enjellic Systems Development, LLC self-defensive IOT platforms 4206 N. 19th Ave. and edge devices. Fargo, ND 58102 PH: 701-281-1686 EMAIL: g...@enjellic.com -- "The best way to predict the future is to invent it." -- Alan Kay
Re: [PATCH v3 3/3] mm/page_alloc: Keep memoryless cpuless node 0 offline
On Fri, 1 May 2020, Srikar Dronamraju wrote:
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -116,8 +116,10 @@ EXPORT_SYMBOL(latent_entropy);
> */
> nodemask_t node_states[NR_NODE_STATES] __read_mostly = {
> [N_POSSIBLE] = NODE_MASK_ALL,
> +#ifdef CONFIG_NUMA
> + [N_ONLINE] = NODE_MASK_NONE,
Hmmm I would have expected that you would have added something early
in boot that would mark the current node (whatever is is) online instead?
Re: [PATCH v2 2/3] media: uapi: Add VP9 stateless decoder controls
+Nicolas
On Sat, 2020-05-02 at 20:37 +0200, Boris Brezillon wrote:
> On Fri, 01 May 2020 13:57:49 -0300
> Ezequiel Garcia wrote:
>
> > > > +
> > > > +.. tabularcolumns:: |p{1.5cm}|p{6.3cm}|p{9.4cm}|
> > > > +
> > > > +.. flat-table:: enum v4l2_vp9_reset_frame_context
> > > > +:header-rows: 0
> > > > +:stub-columns: 0
> > > > +:widths: 1 2
> > > > +
> > > > +* - ``V4L2_VP9_RESET_FRAME_CTX_NONE``
> > > > + - Do not reset any frame context.
> > > > +* - ``V4L2_VP9_RESET_FRAME_CTX_NONE_ALT``
> > > > + - Do not reset any frame context. This is an alternative value
> > > > for
> > > > +V4L2_VP9_RESET_FRAME_CTX_NONE.
> > >
> > > Add `` around V4L2_VP9_RESET_FRAME_CTX_NONE.
> > >
> >
> > Hm, now that I look closer, what's the point
> > of having the NONE_ALT in our uAPI if it
> > has same meaning as NONE?
> >
> > I think it can be removed.
>
> The intent was to match the spec so that one can pass the value
> extracted from the bitstream directly.
>
> > > I got several smatch warnings:
> > >
> > > smatch: ERRORS
> > > drivers/media/v4l2-core/v4l2-ctrls.c:1880
> > > validate_vp9_frame_decode_params() warn: was && intended here instead of
> > > ||?
> > >
> > > (Commented on this ^^^ one above)
> > >
> > > drivers/staging/media/rkvdec/rkvdec-vp9.c:426 init_intra_only_probs()
> > > error: buffer overflow 'ptr' 9 <= 69
> > > drivers/staging/media/rkvdec/rkvdec-vp9.c:1478 rkvdec_vp9_done() error:
> > > potentially dereferencing uninitialized 'ctrl'.
> > > drivers/staging/media/rkvdec/rkvdec-vp9.c:1483 rkvdec_vp9_done() error:
> > > uninitialized symbol 'dec_dst_buf'.
> > > drivers/staging/media/rkvdec/rkvdec-vp9.c:941:6: warning: variable 'ret'
> > > set but not used [-Wunused-but-set-variable]
> > > drivers/staging/media/rkvdec/rkvdec-vp9.c:1466:40: warning: variable
> > > 'fctx' set but not used [-Wunused-but-set-variable]
> > >
> >
> > Oh, I'll run smatch and fix them all.
>
> Oops!
Re: [PATCH v3 1/3] powerpc/numa: Set numa_node for all possible cpus
On Fri, 1 May 2020, Srikar Dronamraju wrote:
> - for_each_present_cpu(cpu)
> - numa_setup_cpu(cpu);
> + for_each_possible_cpu(cpu) {
> + /*
> + * Powerpc with CONFIG_NUMA always used to have a node 0,
> + * even if it was memoryless or cpuless. For all cpus that
> + * are possible but not present, cpu_to_node() would point
> + * to node 0. To remove a cpuless, memoryless dummy node,
> + * powerpc need to make sure all possible but not present
> + * cpu_to_node are set to a proper node.
> + */
> + if (cpu_present(cpu))
> + numa_setup_cpu(cpu);
> + else
> + set_cpu_numa_node(cpu, first_online_node);
> + }
> }
Can this be folded into numa_setup_cpu?
This looks more like numa_setup_cpu needs to change?
Re: [RFC PATCH v11 6/9] media: tegra: Add Tegra210 Video input driver
On 5/2/20 1:48 PM, Dmitry Osipenko wrote: 02.05.2020 19:55, Sowjanya Komatineni пишет: Also stop stream ioctl request happens during suspend where both threads will be stopped properly. done thread stop happens only after finishing all outstanding buffers. Do you mean that V4L core takes care of stopping the streami on suspend and re-starting it on resume from suspend? Stop stream request happens from streaming applications so even without driver suspend/resume implementation currently, streaming will be stopped prior to system suspend where both threads will be stopped properly (after finishing out standing buffers) and will be resumed by application on system resume All userspace is frozen on suspend. System suspension is transparent for userspace applications. I'm not sure what you're meaning here. Also tested suspending while streaming with this unconditional freeze, I don't see any issue as application stops stream where v4l_streamoff gets executed during suspend and on resume streaming starts where v4l_streamon happens. So, I don't see any issue with existing implementation of unconditional freeze. I don't understand why freezing is needed at all if V4L core takes care of stopping the stream on suspend, what is the point? If there is no real point, then let's make threads non-freezable and done with that. video device fops unlocked_ioctl is set to video_ioctl2() in vi driver. video device fops unlocked_ioctl gets executed with stream off cmd during suspend and stream on cmd during resume which eventually calls v4l_streamoff and v4l_streamon during system suspend/resume. My understanding to have freezable threads is during system suspend user space applications are frozen prior to kernel freeze and during suspend when opened video character device node gets closed these ioctl gets invoked and stream off during suspend and stream on during resume happens. So probably we still need to use freezable threads to sync with user space application when frozen before really entering suspend. Will wait for Thierry/Hans comment to correct if my above understanding is wrong and help clarify if we need freezable threads at all in this case... Note: I see other drivers using freezable threads for capture drivers. Assuming we use freezable threads, I was saying we don't need conditional try_to_freeze() like you pointed because even if finish thread freeze happens prior to frame capture initiated by start thread, vi hardware will still continue to update this single ongoing buffer and will finish max within 200ms and actually there is no direct processing of this done by finish thread itself except that it returns buffers back when done and in this case it returns back when unfreeze/wake up happens. So, I don't see any issue of unconditional try_to_freeze() even with freezable threads. Thanks Sowjanya
Re: [PATCH v4 2/4] power: supply: core: add input voltage/current measurements
On Sun, May 03, 2020 at 12:23:49AM +0200, Sebastian Reichel wrote:
> Hi,
>
> On Fri, May 01, 2020 at 05:11:18PM +0200, Michał Mirosław wrote:
> > Introduce input voltage and current limits and measurements.
> > This makes room for e.g. VBUS measurements in USB chargers.
> We already have properties for charger input voltage/current.
> Unfortunately the naming is not as straight forward, as it
> could be. Basically the properties have been added over time
> and are ABI now. Things are documented in
>
> Documentation/ABI/testing/sysfs-class-power
>
> I provided the relevant properties below.
Hmm. Looks like there is no battery current/voltage properties then?
This is different from IBUS (input current), as IBUS = charging
current + system load. Documentation/power/power_supply_class.rst is
missing descriptions for the properties you mention.
[...]
> > --- a/include/linux/power_supply.h
> > +++ b/include/linux/power_supply.h
> > @@ -127,7 +127,9 @@ enum power_supply_property {
> > POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
> > POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD, /* in percents! */
> > POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD, /* in percents! */
> > + POWER_SUPPLY_PROP_INPUT_CURRENT_NOW,
>
> What: /sys/class/power_supply//current_avg
> Date: May 2007
> Contact:linux...@vger.kernel.org
> Description:
> Reports an average IBUS current reading over a fixed period.
>
> Normally devices will provide a fixed interval in which they
>
> average readings to smooth out the reported value.
>
>
>
> Access: Read
> Valid values: Represented in microamps
>
There are two entries for /sys/class/power_supply//current_avg
in the file, the other one mentions IBAT instead. "voltage_now" has the
same problem. There seems to be a split-personality disorder present in
the kernel ABI. ;-)
Best Regards,
Michał Mirosław
[PATCH] nfp: abm: fix a memory leak bug
From: Qiushi Wu
In function nfp_abm_vnic_set_mac, pointer nsp is allocated by nfp_nsp_open.
But when nfp_nsp_has_hwinfo_lookup fail, the pointer is not released,
which can lead to a memory leak bug. Fix this issue by adding
nfp_nsp_close(nsp) in the error path.
Signed-off-by: Qiushi Wu
---
drivers/net/ethernet/netronome/nfp/abm/main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/netronome/nfp/abm/main.c
b/drivers/net/ethernet/netronome/nfp/abm/main.c
index 9183b3e85d21..354efffac0f9 100644
--- a/drivers/net/ethernet/netronome/nfp/abm/main.c
+++ b/drivers/net/ethernet/netronome/nfp/abm/main.c
@@ -283,6 +283,7 @@ nfp_abm_vnic_set_mac(struct nfp_pf *pf, struct nfp_abm
*abm, struct nfp_net *nn,
if (!nfp_nsp_has_hwinfo_lookup(nsp)) {
nfp_warn(pf->cpp, "NSP doesn't support PF MAC generation\n");
eth_hw_addr_random(nn->dp.netdev);
+ nfp_nsp_close(nsp);
return;
}
--
2.17.1
Re: [PATCH] power: supply: fix memory leaks
Hi,
On Sat, May 02, 2020 at 04:10:56PM -0500, wu000...@umn.edu wrote:
> From: Qiushi Wu
>
> In function power_supply_add_hwmon_sysfs(), psyhw->props is
> allocated by bitmap_zalloc(). But this pointer is not deallocated
> in several error paths, which lead to memory leak bugs. To fix
> this, we can call bitmap_free() to free this pointer.
>
> Signed-off-by: Qiushi Wu
> ---
You are correct, that there is a problem in the first instance, but
the other changes are incorrect and introduce a new double free. Please
read documentation for devm_add_action(). The proper fix is to just
replace the call to devm_add_action() with devm_add_action_or_reset().
Please send a new version for this. Also please add the following
tag:
Fixes: e67d4dfc9ff19 ("power: supply: Add HWMON compatibility layer")
Thanks,
-- Sebastian
> drivers/power/supply/power_supply_hwmon.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/power/supply/power_supply_hwmon.c
> b/drivers/power/supply/power_supply_hwmon.c
> index 75cf861ba492..7453390ab7a4 100644
> --- a/drivers/power/supply/power_supply_hwmon.c
> +++ b/drivers/power/supply/power_supply_hwmon.c
> @@ -307,7 +307,7 @@ int power_supply_add_hwmon_sysfs(struct power_supply *psy)
> ret = devm_add_action(dev, power_supply_hwmon_bitmap_free,
> psyhw->props);
> if (ret)
> - goto error;
> + goto out_free;
>
> for (i = 0; i < desc->num_properties; i++) {
> const enum power_supply_property prop = desc->properties[i];
> @@ -342,7 +342,7 @@ int power_supply_add_hwmon_sysfs(struct power_supply *psy)
> new_name = devm_kstrdup(dev, name, GFP_KERNEL);
> if (!new_name) {
> ret = -ENOMEM;
> - goto error;
> + goto out_free;
> }
> strreplace(new_name, '-', '_');
> name = new_name;
> @@ -353,10 +353,12 @@ int power_supply_add_hwmon_sysfs(struct power_supply
> *psy)
> NULL);
> ret = PTR_ERR_OR_ZERO(hwmon);
> if (ret)
> - goto error;
> + goto out_free;
>
> devres_close_group(dev, power_supply_add_hwmon_sysfs);
> return 0;
> +out_free:
> + bitmap_free(psyhw->props);
> error:
> devres_release_group(dev, NULL);
> return ret;
> --
> 2.17.1
>
signature.asc
Description: PGP signature
Re: [PATCH v2] dt-bindings: power: Convert power_supply text to yaml
Hi,
On Fri, May 01, 2020 at 12:29:13PM -0500, Dan Murphy wrote:
> Convert the power_supply.txt to power-supply.yaml.
> This conversion entailed fixing up the binding to being yaml and dt
> checker compliant.
>
> Added a note in the power_supply.txt to reference the power-supply.yaml
>
> Signed-off-by: Dan Murphy
> ---
Thanks, queued.
-- Sebastian
> .../bindings/power/supply/power-supply.yaml | 40 +++
> .../bindings/power/supply/power_supply.txt| 25 +---
> 2 files changed, 42 insertions(+), 23 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/power/supply/power-supply.yaml
>
> diff --git a/Documentation/devicetree/bindings/power/supply/power-supply.yaml
> b/Documentation/devicetree/bindings/power/supply/power-supply.yaml
> new file mode 100644
> index ..3bb02bb3a2d8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/power-supply.yaml
> @@ -0,0 +1,40 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/power/supply/power-supply.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Power Supply Core Support
> +
> +maintainers:
> + - Sebastian Reichel
> +
> +properties:
> + power-supplies:
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +description:
> + This property is added to a supply in order to list the devices which
> + supply it power, referenced by their phandles.
> +
> +examples:
> + - |
> +power {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + usb_charger:charger@e {
> +compatible = "some,usb-charger";
> +reg = <0xe>;
> + };
> +
> + ac_charger:charger@c {
> +compatible = "some,ac-charger";
> +reg = <0xc>;
> + };
> +
> + battery:battery@b {
> +compatible = "some,battery";
> +reg = <0xb>;
> +power-supplies = <_charger>, <_charger>;
> + };
> +};
> diff --git a/Documentation/devicetree/bindings/power/supply/power_supply.txt
> b/Documentation/devicetree/bindings/power/supply/power_supply.txt
> index 8391bfa0edac..d9693e054509 100644
> --- a/Documentation/devicetree/bindings/power/supply/power_supply.txt
> +++ b/Documentation/devicetree/bindings/power/supply/power_supply.txt
> @@ -1,23 +1,2 @@
> -Power Supply Core Support
> -
> -Optional Properties:
> - - power-supplies : This property is added to a supply in order to list the
> - devices which supply it power, referenced by their phandles.
> -
> -Example:
> -
> - usb-charger: power@e {
> - compatible = "some,usb-charger";
> - ...
> - };
> -
> - ac-charger: power@c {
> - compatible = "some,ac-charger";
> - ...
> - };
> -
> - battery@b {
> - compatible = "some,battery";
> - ...
> - power-supplies = <>, <>;
> - };
> +This binding has been converted to yaml please see power-supply.yaml in this
> +directory.
> --
> 2.25.1
>
signature.asc
Description: PGP signature
Re: [PATCH v4 1/4] power: supply: core: tabularize HWMON temperature labels
Hi,
On Fri, May 01, 2020 at 05:11:18PM +0200, Michał Mirosław wrote:
> Rework power_supply_hwmon_read_string() to check it's parameters.
> This allows to extend it later with labels for other types of
> measurements.
>
> Signed-off-by: Michał Mirosław
> ---
> v2: split from fix temperature labels
> v3: remove power_supply_hwmon_read_string() parameter checks
> as it is internal API (suggested by Guenter Roeck)
> v4: remove unreachable() as it triggers compiler bugs
> ---
Thanks, queued.
-- Sebastian
> drivers/power/supply/power_supply_hwmon.c | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/supply/power_supply_hwmon.c
> b/drivers/power/supply/power_supply_hwmon.c
> index af72e5693f65..f5d538485aaa 100644
> --- a/drivers/power/supply/power_supply_hwmon.c
> +++ b/drivers/power/supply/power_supply_hwmon.c
> @@ -13,6 +13,11 @@ struct power_supply_hwmon {
> unsigned long *props;
> };
>
> +static const char *const ps_temp_label[] = {
> + "temp",
> + "ambient temp",
> +};
> +
> static int power_supply_hwmon_in_to_property(u32 attr)
> {
> switch (attr) {
> @@ -180,7 +185,20 @@ static int power_supply_hwmon_read_string(struct device
> *dev,
> u32 attr, int channel,
> const char **str)
> {
> - *str = channel ? "temp ambient" : "temp";
> + switch (type) {
> + case hwmon_temp:
> + *str = ps_temp_label[channel];
> + break;
> + default:
> + /* unreachable, but see:
> + * gcc bug #51513 [1] and clang bug #978 [2]
> + *
> + * [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51513
> + * [2] https://github.com/ClangBuiltLinux/linux/issues/978
> + */
> + break;
> + }
> +
> return 0;
> }
>
> --
> 2.20.1
>
signature.asc
Description: PGP signature
Re: [PATCH v4 2/4] power: supply: core: add input voltage/current measurements
Hi,
On Fri, May 01, 2020 at 05:11:18PM +0200, Michał Mirosław wrote:
> Introduce input voltage and current limits and measurements.
> This makes room for e.g. VBUS measurements in USB chargers.
We already have properties for charger input voltage/current.
Unfortunately the naming is not as straight forward, as it
could be. Basically the properties have been added over time
and are ABI now. Things are documented in
Documentation/ABI/testing/sysfs-class-power
I provided the relevant properties below.
> Signed-off-by: Michał Mirosław
[...]
> --- a/drivers/power/supply/power_supply_sysfs.c
> +++ b/drivers/power/supply/power_supply_sysfs.c
> @@ -273,7 +273,9 @@ static struct device_attribute power_supply_attrs[] = {
> POWER_SUPPLY_ATTR(charge_control_limit_max),
> POWER_SUPPLY_ATTR(charge_control_start_threshold),
> POWER_SUPPLY_ATTR(charge_control_end_threshold),
> + POWER_SUPPLY_ATTR(input_current_now),
> POWER_SUPPLY_ATTR(input_current_limit),
> + POWER_SUPPLY_ATTR(input_voltage_now),
> POWER_SUPPLY_ATTR(input_voltage_limit),
> POWER_SUPPLY_ATTR(input_power_limit),
> POWER_SUPPLY_ATTR(energy_full_design),
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 6a34df65d4d1..5313d1284aad 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -127,7 +127,9 @@ enum power_supply_property {
> POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
> POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD, /* in percents! */
> POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD, /* in percents! */
> + POWER_SUPPLY_PROP_INPUT_CURRENT_NOW,
What: /sys/class/power_supply//current_avg
Date: May 2007
Contact:linux...@vger.kernel.org
Description:
Reports an average IBUS current reading over a fixed period.
Normally devices will provide a fixed interval in which they
average readings to smooth out the reported value.
Access: Read
Valid values: Represented in microamps
> POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
> + POWER_SUPPLY_PROP_INPUT_VOLTAGE_NOW,
What: /sys/class/power_supply//voltage_now
Date: May 2007
Contact:linux...@vger.kernel.org
Description:
Reports the VBUS voltage supplied now. This value is generally
read-only reporting, unless the 'online' state of the supply
is set to be programmable, in which case this value can be set
within the reported min/max range.
Access: Read, Write
Valid values: Represented in microvolts
> POWER_SUPPLY_PROP_INPUT_VOLTAGE_LIMIT,
> POWER_SUPPLY_PROP_INPUT_POWER_LIMIT,
> POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
-- Sebastian
signature.asc
Description: PGP signature
Re: [RFC, WIP, v4 07/11] media: vidtv: add MPEG TS common code
Hi Mauro, thanks for reviewing this!
> Em Sat, 2 May 2020 00:22:12 -0300
> "Daniel W. S. Almeida" escreveu:
>
>> From: "Daniel W. S. Almeida"
>>
>> Add code to work with MPEG TS packets, such as TS headers, adaptation
>> fields, PCR packets and NULL packets.
>>
>> Signed-off-by: Daniel W. S. Almeida
>> ---
>> drivers/media/test-drivers/vidtv/Makefile | 2 +-
>> drivers/media/test-drivers/vidtv/vidtv_ts.c | 130
>> drivers/media/test-drivers/vidtv/vidtv_ts.h | 103
>> 3 files changed, 234 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/media/test-drivers/vidtv/vidtv_ts.c
>> create mode 100644 drivers/media/test-drivers/vidtv/vidtv_ts.h
>>
>> diff --git a/drivers/media/test-drivers/vidtv/Makefile
b/drivers/media/test-drivers/vidtv/Makefile
>> index 9ea9485d42189..92001bc348615 100644
>> --- a/drivers/media/test-drivers/vidtv/Makefile
>> +++ b/drivers/media/test-drivers/vidtv/Makefile
>> @@ -1,6 +1,6 @@
>> # SPDX-License-Identifier: GPL-2.0
>>
>> vidtv_demod-objs := vidtv_common.o
>> -vidtv_bridge-objs := vidtv_common.o
>> +vidtv_bridge-objs := vidtv_common.o vidtv_ts.o
>>
>> obj-$(CONFIG_DVB_VIDTV) += vidtv_tuner.o vidtv_demod.o vidtv_bridge.o
>> diff --git a/drivers/media/test-drivers/vidtv/vidtv_ts.c
b/drivers/media/test-drivers/vidtv/vidtv_ts.c
>> new file mode 100644
>> index 0..f545c45c0fe7c
>> --- /dev/null
>> +++ b/drivers/media/test-drivers/vidtv/vidtv_ts.c
>> @@ -0,0 +1,130 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * The Virtual DVB test driver serves as a reference DVB driver and
helps
>> + * validate the existing APIs in the media subsystem. It can also aid
>> + * developers working on userspace applications.
>> + *
>> + * Written by Daniel W. S. Almeida
>> + */
>> +
>> +#include
>> +#include
>> +#include "vidtv_ts.h"
>> +#include "vidtv_common.h"
>> +
>> +static u32 vidtv_ts_write_pcr_bits(u8 *buf, u64 pcr)
>> +{
>> + /* Exact same from ffmpeg. PCR is a counter driven by a 27Mhz clock */
>> + u64 pcr_low = pcr % 300, pcr_high = pcr / 300;
>> +
>> + *buf++ = pcr_high >> 25;
>> + *buf++ = pcr_high >> 17;
>> + *buf++ = pcr_high >> 9;
>> + *buf++ = pcr_high >> 1;
>> + *buf++ = pcr_high << 7 | pcr_low >> 8 | 0x7e;
>> + *buf++ = pcr_low;
>> +
>> + return 6;
>> +}
>> +
>> +void vidtv_ts_inc_cc(u8 *continuity_counter)
>> +{
>> + ++*continuity_counter;
>> + if (*continuity_counter > TS_CC_MAX_VAL)
>> + *continuity_counter = 0;
>> +}
>> +
>> +u32 vidtv_ts_null_write_into(struct null_packet_write_args args)
>> +{
>> + u32nbytes = 0;
>> + struct vidtv_mpeg_ts ts_header = {0};
>> +
>> + ts_header.sync_byte = TS_SYNC_BYTE;
>> + ts_header.pid= TS_NULL_PACKET_PID;
>> + ts_header.payload= 1;
>> + ts_header.continuity_counter = *args.continuity_counter;
>> +
>> + cpu_to_be16s(_header.bitfield);
>> +
>> + /* copy TS header */
>> + nbytes += vidtv_memcpy(args.dest_buf + args.dest_offset + nbytes,
>> + _header,
>> + sizeof(ts_header),
>> + args.dest_offset + nbytes,
>> + args.buf_sz);
>
> Hmm... now I see why you're returning 0 to vidtv_memcpy().
>
> Yet, if the buffer is full, you should just drop the entire package,
> as otherwise you may end copying things that aren't multiple of 188
bytes,
> causing sync issues at the client.
I'd like to provide a counterargument for this.
The way I am dealing with errors throughout vidtv so far is:
If we hit any of these WARN_ON macros, pr_err and the like, then all
bets are off. This means that the resulting stream will likely be
invalid and that something needs to be rewritten in the source code and
my main concern is then preventing the whole driver from crashing.
This is exactly the behavior that you see in vidtv_memcpy and
vidtv_memset: nothing gets written so we don't end up with an overflow,
a diagnostic message is printed and there are no attempts at recovery.
In this particular example, I compromised by allowing the size of the
buffer to be a module param, i.e.
>> +static unsigned int ts_buf_sz = 20 * 188;
>> +module_param(ts_buf_sz, uint, 0644);
>> +MODULE_PARM_DESC(ts_buf_sz, "Optional size for the TS buffer");
I think that what I am trying to say is better seen in the last patch
for this series: [RFC, WIP, v4 11/11] media: vidtv: Add a MPEG Transport
Stream Multiplexer.
The following takes place in vidtv_mux.c:
1. We wake up from sleep, take note of how long we slept for and store
it into "elapsed_time". This is usually between 10ms and 20ms.
2. We encode "elapsed_time" miliseconds worth of data into a buffer
3. We call dvb_dmx_swfilter(), passing a pointer to the buffer
4. We clear the buffer, sleep for a bit and then go back
[PATCH 1/2] staging: vt6655: return early if not bNeedAck
This patch will check for bNeedAck before making bb_get_frame_time call, so in case we dont need uAckTime, we can return early. Signed-off-by: Matej Dujava --- drivers/staging/vt6655/rxtx.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c index 2f9c2ead3cb8..dda578436e64 100644 --- a/drivers/staging/vt6655/rxtx.c +++ b/drivers/staging/vt6655/rxtx.c @@ -166,15 +166,16 @@ s_uGetTxRsvTime( unsigned int uDataTime, uAckTime; uDataTime = bb_get_frame_time(pDevice->byPreambleType, byPktType, cbFrameLength, wRate); + + if (!bNeedAck) + return uDataTime; + if (byPktType == PK_TYPE_11B) /* llb,CCK mode */ uAckTime = bb_get_frame_time(pDevice->byPreambleType, byPktType, 14, (unsigned short)pDevice->byTopCCKBasicRate); else /* 11g 2.4G OFDM mode & 11a 5G OFDM mode */ uAckTime = bb_get_frame_time(pDevice->byPreambleType, byPktType, 14, (unsigned short)pDevice->byTopOFDMBasicRate); - if (bNeedAck) - return uDataTime + pDevice->uSIFS + uAckTime; - else - return uDataTime; + return uDataTime + pDevice->uSIFS + uAckTime; } static __le16 vnt_rxtx_rsvtime_le16(struct vnt_private *priv, u8 pkt_type, -- 2.26.2
[PATCH 2/2] staging: vt6655: fix LONG_LINE warning
This patch will fix LONG_LINE error from checkpatch, by createing temporary
variable so call to the function is not in if/else block.
Signed-off-by: Matej Dujava
---
drivers/staging/vt6655/rxtx.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
index dda578436e64..782177dfd67e 100644
--- a/drivers/staging/vt6655/rxtx.c
+++ b/drivers/staging/vt6655/rxtx.c
@@ -164,16 +164,24 @@ s_uGetTxRsvTime(
)
{
unsigned int uDataTime, uAckTime;
+ unsigned short basic_rate;
uDataTime = bb_get_frame_time(pDevice->byPreambleType, byPktType,
cbFrameLength, wRate);
if (!bNeedAck)
return uDataTime;
- if (byPktType == PK_TYPE_11B) /* llb,CCK mode */
- uAckTime = bb_get_frame_time(pDevice->byPreambleType,
byPktType, 14, (unsigned short)pDevice->byTopCCKBasicRate);
- else /* 11g 2.4G OFDM mode & 11a 5G OFDM mode */
- uAckTime = bb_get_frame_time(pDevice->byPreambleType,
byPktType, 14, (unsigned short)pDevice->byTopOFDMBasicRate);
+ /*
+* CCK mode - 11b
+* OFDM mode - 11g 2.4G & 11a 5G
+*/
+ if (byPktType == PK_TYPE_11B)
+ basic_rate = (unsigned short)pDevice->byTopCCKBasicRate;
+ else
+ basic_rate = (unsigned short)pDevice->byTopOFDMBasicRate;
+
+ uAckTime = bb_get_frame_time(pDevice->byPreambleType, byPktType, 14,
+basic_rate);
return uDataTime + pDevice->uSIFS + uAckTime;
}
--
2.26.2
Re: [PATCH 2/2] drm/panfrost: add devfreq regulator support
Hi Steven, On Tue, 14 Apr 2020 at 15:10, Steven Price wrote: > > Hi Clément, > > On 13/04/2020 18:28, Clément Péron wrote: > > Hi Steven, > > > Getting a backtrace from the two occurrences, I see one added from: > >(debugfs_create_dir) from [] (create_regulator+0xe0/0x220) >(create_regulator) from [] (_regulator_get+0x168/0x204) >(_regulator_get) from [] (regulator_bulk_get+0x64/0xf4) >(regulator_bulk_get) from [] > (devm_regulator_bulk_get+0x40/0x74) >(devm_regulator_bulk_get) from [] > (panfrost_device_init+0x1b4/0x48c [panfrost]) >(panfrost_device_init [panfrost]) from [] > (panfrost_probe+0x94/0x184 [panfrost]) >(panfrost_probe [panfrost]) from [] > (platform_drv_probe+0x48/0x94) > > And the other: > >(debugfs_create_dir) from [] (create_regulator+0xe0/0x220) >(create_regulator) from [] (_regulator_get+0x168/0x204) >(_regulator_get) from [] (dev_pm_opp_set_regulators+0x6c/0x184) >(dev_pm_opp_set_regulators) from [] > (panfrost_devfreq_init+0x38/0x1ac [panfrost]) >(panfrost_devfreq_init [panfrost]) from [] > (panfrost_probe+0xc8/0x184 [panfrost]) >(panfrost_probe [panfrost]) from [] > (platform_drv_probe+0x48/0x94) > > Both are created at /regulator/vdd_gpu I'm preparing a new version with some clean from lima devfreq. My working branch : https://github.com/clementperon/linux/commits/panfrost_devfreq Two strange things I observe: - After 30sec the regulator is released by OPP ??? [ 33.757627] vdd-gpu: disabling Introduce the regulator support in this commit: https://github.com/clementperon/linux/commit/be310c37b82010e293b7f129ccdcb711a2abb2ce - The Cooling map is not probe correctly : [2.545756] panfrost 180.gpu: [drm:panfrost_devfreq_init [panfrost]] Failed to register cooling device Introduce in this commit : https://github.com/clementperon/linux/commit/0252c38fd55ad78366ac4b1714e285c88db34557 Do you have an hint about what I'm missing ? Thanks for your help, Clement
Re: [PATCH v23 02/16] leds: multicolor: Introduce a multicolor class definition
Dan, I've converted drivers/leds/leds-an30259a.c to LED mc framework and tested it on Samsung Galaxy S3 (exysnos4412-trats2 board). Works as expected. And now the framework usability is indeed neater. One thing to improve: LED mc based drivers' entries in Kconfig should have this dependency: depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR It is required to enforce building driver as a module if LED mc framework is configured as such. With this (and DT bindings nits) addressed, for patches 1-6: Acked-by: Jacek Anaszewski It's been a long journey. Thank you for your determination to drive this work to the end. Best regards, Jacek Anaszewski On 4/29/20 10:28 PM, Dan Murphy wrote: Introduce a multicolor class that groups colored LEDs within a LED node. The multi color class groups monochrome LEDs and allows controlling two aspects of the final combined color: hue and lightness. The former is controlled via the intensity file and the latter is controlled via brightness file. Signed-off-by: Dan Murphy --- .../ABI/testing/sysfs-class-led-multicolor| 34 +++ Documentation/leds/index.rst | 1 + Documentation/leds/leds-class-multicolor.rst | 86 +++ MAINTAINERS | 8 + drivers/leds/Kconfig | 10 + drivers/leds/Makefile | 1 + drivers/leds/led-class-multicolor.c | 210 ++ include/linux/led-class-multicolor.h | 121 ++ 8 files changed, 471 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-led-multicolor create mode 100644 Documentation/leds/leds-class-multicolor.rst create mode 100644 drivers/leds/led-class-multicolor.c create mode 100644 include/linux/led-class-multicolor.h [...]
Re: [PATCH v23 01/16] dt: bindings: Add multicolor class dt bindings documention
Dan,
Thanks for improving the bindings. Now we have one indentation
related issue, please look below at the example.
On 4/29/20 10:28 PM, Dan Murphy wrote:
Add DT bindings for the LEDs multicolor class framework.
Add multicolor ID to the color ID list for device tree bindings.
CC: Rob Herring
Acked-by: Pavel Machek
Signed-off-by: Dan Murphy
---
.../bindings/leds/leds-class-multicolor.yaml | 70 +++
drivers/leds/led-core.c | 1 +
include/dt-bindings/leds/common.h | 3 +-
3 files changed, 73 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
diff --git a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
new file mode 100644
index ..e6169ed5ed12
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-class-multicolor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common properties for the multicolor LED class.
+
+maintainers:
+ - Dan Murphy
+
+description: |
+ Bindings for multi color LEDs show how to describe current outputs of
+ either integrated multi-color LED elements (like RGB, RGBW, RGBWA-UV
+ etc.) or standalone LEDs, to achieve logically grouped multi-color LED
+ modules. This is achieved by adding multi-led nodes layer to the
+ monochrome LED bindings.
+ The nodes and properties defined in this document are unique to the
multicolor
+ LED class. Common LED nodes and properties are inherited from the common.txt
+ within this documentation directory.
+
+properties:
+ color:
+description: |
+ For multicolor LED support this property should be defined as
+ LED_COLOR_ID_MULTI and further definition can be found in
+ include/linux/leds/common.h.
+
+required:
+ - color
+
+examples:
+ - |
+#include
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
It would look neater if we had an empty line here.
+led-controller@14 {
We should have one more level of indentation below
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "ti,lp5009";
+reg = <0x14>;
+
+multi-led@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ color = ;
+ function = LED_FUNCTION_CHARGING;
+
+ led@0 {
+reg = <0>;
+color = ;
+ };
+
+ led@1 {
+reg = <1>;
+color = ;
+ };
+
+ led@2 {
+reg = <2>;
+color = ;
+ };
+};
+ };
+};
+
+additionalProperties: false
+...
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index f1f718dbe0f8..846248a0693d 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -34,6 +34,7 @@ const char * const led_colors[LED_COLOR_ID_MAX] = {
[LED_COLOR_ID_VIOLET] = "violet",
[LED_COLOR_ID_YELLOW] = "yellow",
[LED_COLOR_ID_IR] = "ir",
+ [LED_COLOR_ID_MULTI] = "multicolor",
};
EXPORT_SYMBOL_GPL(led_colors);
diff --git a/include/dt-bindings/leds/common.h b/include/dt-bindings/leds/common.h
index 0ce7dfc00dcb..a463ce6a8794 100644
--- a/include/dt-bindings/leds/common.h
+++ b/include/dt-bindings/leds/common.h
@@ -30,7 +30,8 @@
#define LED_COLOR_ID_VIOLET 5
#define LED_COLOR_ID_YELLOW 6
#define LED_COLOR_ID_IR 7
-#define LED_COLOR_ID_MAX 8
+#define LED_COLOR_ID_MULTI 8
+#define LED_COLOR_ID_MAX 9
/* Standard LED functions */
/* Keyboard LEDs, usually it would be input4::capslock etc. */
Re: [PATCH 0/2] ALSA: line6: hwdep: add support for poll and non-blocking read
On Sat, May 2, 2020 at 1:32 PM Takashi Iwai wrote: > > On Sat, 02 May 2020 21:31:18 +0200, > Vasily Khoruzhick wrote: > > > > This series adds support for polling and non-blocking read for hwdep > > interface. This allows apps to listen to HW events without using busy > > loop. > > > > Example of app that uses hwdep interface for POD HD500 can be found > > here: https://github.com/anarsoul/line6_hwdep_test > > > > Vasily Khoruzhick (2): > > ALSA: line6: hwdep: add support for O_NONBLOCK opening mode > > ALSA: line6: Add poll callback for hwdep > > Looks like a nice extension. Applied both patches now to for-next > branch. Thanks for such a prompt response! > > thanks, > > Takashi
Re: [RFC, WIP, v4 05/11] media: vidtv: add a bridge driver
Hi Mauro, thanks for reviewing this.
On 5/2/20 3:30 AM, Mauro Carvalho Chehab wrote:
> Em Sat, 2 May 2020 00:22:10 -0300
> "Daniel W. S. Almeida" escreveu:
>
>> From: "Daniel W. S. Almeida"
>>
>> Digital TV devices consist of several independent hardware
components which
>> are controlled by different drivers.
>> Each media device is controlled by a group of cooperating drivers
with the
>> bridge driver as the main driver.
>>
>> This patch adds a bridge driver for the Virtual Digital TV driver
[vidtv].
>>
>> The bridge driver binds to the other drivers, that is, vidtv_tuner and
>> vidtv_demod and implements the digital demux logic, providing userspace
>> with a MPEG Transport Stream.
>>
>> Move config structs to a common header so they can be used by the bridge
>> driver and by their respective drivers.
>>
>> Signed-off-by: Daniel W. S. Almeida
>> ---
>> drivers/media/test-drivers/vidtv/Makefile | 2 +-
>> .../media/test-drivers/vidtv/vidtv_bridge.c | 379 ++
>> .../media/test-drivers/vidtv/vidtv_bridge.h | 37 ++
>> 3 files changed, 417 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/media/test-drivers/vidtv/vidtv_bridge.c
>> create mode 100644 drivers/media/test-drivers/vidtv/vidtv_bridge.h
>>
>> diff --git a/drivers/media/test-drivers/vidtv/Makefile
b/drivers/media/test-drivers/vidtv/Makefile
>> index 36ba00ddc0d1e..a9f1993dd5443 100644
>> --- a/drivers/media/test-drivers/vidtv/Makefile
>> +++ b/drivers/media/test-drivers/vidtv/Makefile
>> @@ -1,3 +1,3 @@
>> # SPDX-License-Identifier: GPL-2.0
>>
>> -obj-$(CONFIG_DVB_VIDTV) += vidtv_tuner.o vidtv_demod.o
>> +obj-$(CONFIG_DVB_VIDTV) += vidtv_tuner.o vidtv_demod.o vidtv_bridge.o
>> diff --git a/drivers/media/test-drivers/vidtv/vidtv_bridge.c
b/drivers/media/test-drivers/vidtv/vidtv_bridge.c
>> new file mode 100644
>> index 0..05ca4027c869f
>> --- /dev/null
>> +++ b/drivers/media/test-drivers/vidtv/vidtv_bridge.c
>> @@ -0,0 +1,379 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * The Virtual DTV test driver serves as a reference DVB driver and
helps
>> + * validate the existing APIs in the media subsystem. It can also aid
>> + * developers working on userspace applications.
>> + *
>> + * Written by Daniel W. S. Almeida
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include "vidtv_bridge.h"
>> +
>> +#define TS_BUF_MAX_SZ (128 * 188)
>> +#define TUNER_DEFAULT_ADDR 0x68
>> +#define DEMOD_DEFAULT_ADDR 0x60
>> +
>> +MODULE_AUTHOR("Daniel W. S. Almeida");
>> +MODULE_LICENSE("GPL");
>> +
>
>> +static unsigned int drop_tslock_prob_on_low_snr;
>> +module_param(drop_tslock_prob_on_low_snr, uint, 0644);
>> +MODULE_PARM_DESC(drop_tslock_prob_on_low_snr,
>> + "Probability of losing the TS lock if the signal quality is
bad");
>> +
>> +static unsigned int recover_tslock_prob_on_good_snr;
>> +module_param(recover_tslock_prob_on_good_snr, uint, 0644);
>> +MODULE_PARM_DESC(recover_tslock_prob_on_good_snr,
>> + "Probability recovering the TS lock when the signal
improves");
>
> The FS permissions should be reviewed. IMHO, we should allow the
> group which owns the /dev to be able to change values when they can
> be changed in runtime.
>
> Yet, be sure that changing it on runtime won't cause race conditions.
>
> For the two above, I guess the permissions for those should be, instead,
> 0664.
>
>> +
>> +static unsigned int mock_power_up_delay_msec;
>> +module_param(mock_power_up_delay_msec, uint, 0644);
>> +MODULE_PARM_DESC(mock_power_up_delay_msec, "Simulate a power up
delay");
>
> What's the sense of allowing changing it after the probe? I guess
> permissions should be 0444 here.
>
>> +
>> +static unsigned int mock_tune_delay_msec;
>> +module_param(mock_tune_delay_msec, uint, 0644);
>> +MODULE_PARM_DESC(mock_tune_delay_msec, "Simulate a tune delay");
>
> Same here: I guess 0664 would work better.
>
>> +
>> +static unsigned int vidtv_valid_dvb_t_freqs[8];
>> +module_param_array(vidtv_valid_dvb_t_freqs, uint, NULL, 0644);
>> +MODULE_PARM_DESC(vidtv_valid_dvb_t_freqs,
>> + "Valid DVB-T frequencies to simulate");
>> +
>> +static unsigned int vidtv_valid_dvb_c_freqs[8];
>> +module_param_array(vidtv_valid_dvb_c_freqs, uint, NULL, 0644);
>> +MODULE_PARM_DESC(vidtv_valid_dvb_c_freqs,
>> + "Valid DVB-C frequencies to simulate");
>> +
>> +static unsigned int vidtv_valid_dvb_s_freqs[8];
>> +module_param_array(vidtv_valid_dvb_s_freqs, uint, NULL, 0644);
>> +MODULE_PARM_DESC(vidtv_valid_dvb_s_freqs,
>> + "Valid DVB-C frequencies to simulate");
>
> Can those be changed in runtime without causing race conditions?
>
>> +
>> +static unsigned int max_frequency_shift_hz;
>> +module_param(max_frequency_shift_hz, uint, 0644);
>> +MODULE_PARM_DESC(max_frequency_shift_hz,
>> + "Maximum shift in HZ allowed when tuning in a channel");
>
> 0664?
>
>> +
>> +static unsigned int
[PATCH] power: supply: fix memory leaks
From: Qiushi Wu
In function power_supply_add_hwmon_sysfs(), psyhw->props is
allocated by bitmap_zalloc(). But this pointer is not deallocated
in several error paths, which lead to memory leak bugs. To fix
this, we can call bitmap_free() to free this pointer.
Signed-off-by: Qiushi Wu
---
drivers/power/supply/power_supply_hwmon.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/power/supply/power_supply_hwmon.c
b/drivers/power/supply/power_supply_hwmon.c
index 75cf861ba492..7453390ab7a4 100644
--- a/drivers/power/supply/power_supply_hwmon.c
+++ b/drivers/power/supply/power_supply_hwmon.c
@@ -307,7 +307,7 @@ int power_supply_add_hwmon_sysfs(struct power_supply *psy)
ret = devm_add_action(dev, power_supply_hwmon_bitmap_free,
psyhw->props);
if (ret)
- goto error;
+ goto out_free;
for (i = 0; i < desc->num_properties; i++) {
const enum power_supply_property prop = desc->properties[i];
@@ -342,7 +342,7 @@ int power_supply_add_hwmon_sysfs(struct power_supply *psy)
new_name = devm_kstrdup(dev, name, GFP_KERNEL);
if (!new_name) {
ret = -ENOMEM;
- goto error;
+ goto out_free;
}
strreplace(new_name, '-', '_');
name = new_name;
@@ -353,10 +353,12 @@ int power_supply_add_hwmon_sysfs(struct power_supply *psy)
NULL);
ret = PTR_ERR_OR_ZERO(hwmon);
if (ret)
- goto error;
+ goto out_free;
devres_close_group(dev, power_supply_add_hwmon_sysfs);
return 0;
+out_free:
+ bitmap_free(psyhw->props);
error:
devres_release_group(dev, NULL);
return ret;
--
2.17.1
Re: [PATCH 0/7] sha1 library cleanup
Thanks for this series. I like the general idea. I think it might make sense, though, to separate things out into sha1.h and sha256.h. That will be nice preparation work for when we eventually move obsolete primitives into some subdirectory.
Re: [Patch] mtd:rawnand: brcmnand: Fix PM resume crash
On 5/2/2020 1:41 PM, Kamal Dasu wrote:
> This change fixes crash observed on PM resume. This bug
> was introduced in the change made for flash-edu support.
>
> Fixes: a5d53ad26a8b ("mtd: rawnand: brcmnand: Add support for flash-edu for
> dma transfers")
>
> Signed-off-by: Kamal Dasu
Acked-by: Florian Fainelli
--
Florian
Re: [RFC PATCH v11 6/9] media: tegra: Add Tegra210 Video input driver
02.05.2020 19:55, Sowjanya Komatineni пишет: > Also stop stream ioctl request happens during suspend where both threads > will be stopped properly. done thread stop happens only after finishing > all outstanding buffers. Do you mean that V4L core takes care of stopping the streami on suspend and re-starting it on resume from suspend? > Stop stream request happens from streaming applications so even without > driver suspend/resume implementation currently, streaming will be > stopped prior to system suspend where both threads will be stopped > properly (after finishing out standing buffers) and will be resumed by > application on system resume All userspace is frozen on suspend. System suspension is transparent for userspace applications. I'm not sure what you're meaning here. > Also tested suspending while streaming with this unconditional freeze, I > don't see any issue as application stops stream where v4l_streamoff gets > executed during suspend and on resume streaming starts where > v4l_streamon happens. > > So, I don't see any issue with existing implementation of unconditional > freeze. I don't understand why freezing is needed at all if V4L core takes care of stopping the stream on suspend, what is the point? If there is no real point, then let's make threads non-freezable and done with that.
[Patch] mtd:rawnand: brcmnand: Fix PM resume crash
This change fixes crash observed on PM resume. This bug
was introduced in the change made for flash-edu support.
Fixes: a5d53ad26a8b ("mtd: rawnand: brcmnand: Add support for flash-edu for dma
transfers")
Signed-off-by: Kamal Dasu
---
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index e4e3ceeac38f..8f9ffb46a09f 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -2728,9 +2728,8 @@ static int brcmnand_resume(struct device *dev)
flash_dma_writel(ctrl, FLASH_DMA_ERROR_STATUS, 0);
}
- if (has_edu(ctrl))
+ if (has_edu(ctrl)) {
ctrl->edu_config = edu_readl(ctrl, EDU_CONFIG);
- else {
edu_writel(ctrl, EDU_CONFIG, ctrl->edu_config);
edu_readl(ctrl, EDU_CONFIG);
brcmnand_edu_init(ctrl);
--
2.17.1
Re: [PATCH 0/2] ALSA: line6: hwdep: add support for poll and non-blocking read
On Sat, 02 May 2020 21:31:18 +0200, Vasily Khoruzhick wrote: > > This series adds support for polling and non-blocking read for hwdep > interface. This allows apps to listen to HW events without using busy > loop. > > Example of app that uses hwdep interface for POD HD500 can be found > here: https://github.com/anarsoul/line6_hwdep_test > > Vasily Khoruzhick (2): > ALSA: line6: hwdep: add support for O_NONBLOCK opening mode > ALSA: line6: Add poll callback for hwdep Looks like a nice extension. Applied both patches now to for-next branch. thanks, Takashi
[PATCH] rtc: mc13xxx: fix a double-unlock issue
From: Qiushi Wu
In function mc13xxx_rtc_probe, the mc13xxx_unlock() is called
before rtc_register_device(). But in the error path of
rtc_register_device(), the mc13xxx_unlock() is called again,
which causes a double-unlock problem. To fix this problem, we
need to call mc13xxx_lock() again in this error path.
Signed-off-by: Qiushi Wu
---
drivers/rtc/rtc-mc13xxx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-mc13xxx.c b/drivers/rtc/rtc-mc13xxx.c
index afce2c0b4bd6..d6802e6191cb 100644
--- a/drivers/rtc/rtc-mc13xxx.c
+++ b/drivers/rtc/rtc-mc13xxx.c
@@ -308,8 +308,10 @@ static int __init mc13xxx_rtc_probe(struct platform_device
*pdev)
mc13xxx_unlock(mc13xxx);
ret = rtc_register_device(priv->rtc);
- if (ret)
+ if (ret) {
+ mc13xxx_lock(mc13xxx);
goto err_irq_request;
+ }
return 0;
--
2.17.1
Re: [PATCH v7 01/12] dt-bindings: add img,pvrsgx.yaml for Imagination GPUs
Hi Paul, > Am 26.04.2020 um 15:11 schrieb Paul Cercueil : > > Hi Nikolaus, > > Le ven. 24 avril 2020 à 22:34, H. Nikolaus Schaller a > écrit : >> The Imagination PVR/SGX GPU is part of several SoC from >> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo, >> Allwinner A83 and others. >> With this binding, we describe how the SGX processor is >> interfaced to the SoC (registers and interrupt). >> The interface also consists of clocks, reset, power but >> information from data sheets is vague and some SoC integrators >> (TI) deciced to use a PRCM wrapper (ti,sysc) which does >> all clock, reset and power-management through registers >> outside of the sgx register block. >> Therefore all these properties are optional. >> Tested by make dt_binding_check >> Signed-off-by: H. Nikolaus Schaller >> --- >> .../devicetree/bindings/gpu/img,pvrsgx.yaml | 150 ++ >> 1 file changed, 150 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml >> diff --git a/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml >> b/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml >> new file mode 100644 >> index ..33a9c4c6e784 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml >> @@ -0,0 +1,150 @@ >> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/gpu/img,pvrsgx.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Imagination PVR/SGX GPU >> + >> +maintainers: >> + - H. Nikolaus Schaller >> + >> +description: |+ >> + This binding describes the Imagination SGX5 series of 3D accelerators >> which >> + are found in several different SoC like TI OMAP, Sitara, Ingenic JZ4780, >> + Allwinner A83, and Intel Poulsbo and CedarView and more. >> + >> + For an extensive list see: >> https://en.wikipedia.org/wiki/PowerVR#Implementations >> + >> + The SGX node is usually a child node of some DT node belonging to the SoC >> + which handles clocks, reset and general address space mapping of the SGX >> + register area. If not, an optional clock can be specified here. >> + >> +properties: >> + $nodename: >> +pattern: '^gpu@[a-f0-9]+$' >> + compatible: >> +oneOf: >> + - description: SGX530-121 based SoC >> +items: >> + - enum: >> +- ti,omap3-sgx530-121 # BeagleBoard A/B/C, OpenPandora 600MHz >> and similar >> + - const: img,sgx530-121 >> + - const: img,sgx530 >> + >> + - description: SGX530-125 based SoC >> +items: >> + - enum: >> +- ti,am3352-sgx530-125 # BeagleBone Black >> +- ti,am3517-sgx530-125 >> +- ti,am4-sgx530-125 >> +- ti,omap3-sgx530-125 # BeagleBoard XM, GTA04, OpenPandora 1GHz >> and similar >> +- ti,ti81xx-sgx530-125 >> + - const: ti,omap3-sgx530-125 >> + - const: img,sgx530-125 >> + - const: img,sgx530 >> + >> + - description: SGX535-116 based SoC >> +items: >> + - const: intel,poulsbo-gma500-sgx535 # Atom Z5xx >> + - const: img,sgx535-116 >> + - const: img,sgx535 >> + >> + - description: SGX540-116 based SoC >> +items: >> + - const: intel,medfield-gma-sgx540 # Atom Z24xx >> + - const: img,sgx540-116 >> + - const: img,sgx540 >> + >> + - description: SGX540-120 based SoC >> +items: >> + - enum: >> +- samsung,s5pv210-sgx540-120 >> +- ti,omap4-sgx540-120 # Pandaboard, Pandaboard ES and similar >> + - const: img,sgx540-120 >> + - const: img,sgx540 >> + >> + - description: SGX540-130 based SoC >> +items: >> + - enum: >> +- ingenic,jz4780-sgx540-130 # CI20 >> + - const: img,sgx540-130 >> + - const: img,sgx540 >> + >> + - description: SGX544-112 based SoC >> +items: >> + - const: ti,omap4470-sgx544-112 >> + - const: img,sgx544-112 >> + - const: img,sgx544 >> + >> + - description: SGX544-115 based SoC >> +items: >> + - enum: >> +- allwinner,sun8i-a31-sgx544-115 >> +- allwinner,sun8i-a31s-sgx544-115 >> +- allwinner,sun8i-a83t-sgx544-115 # Banana-Pi-M3 (Allwinner >> A83T) and similar >> + - const: img,sgx544-115 >> + - const: img,sgx544 >> + >> + - description: SGX544-116 based SoC >> +items: >> + - enum: >> +- ti,dra7-sgx544-116 # DRA7 >> +- ti,omap5-sgx544-116 # OMAP5 UEVM, Pyra Handheld and similar >> + - const: img,sgx544-116 >> + - const: img,sgx544 >> + >> + - description: SGX545 based SoC >> +items: >> + - const: intel,cedarview-gma3600-sgx545 # Atom N2600, D2500 >> + - const: img,sgx545-116 >> + - const: img,sgx545 >> + >> + reg: >> +
Re: [PATCH] drm/meson: viu: fix setting the OSD burst length in VIU_OSD1_FIFO_CTRL_STAT
Hi Neil, On Tue, Apr 28, 2020 at 10:38 AM Neil Armstrong wrote: [...] > > @@ -444,9 +437,9 @@ void meson_viu_init(struct meson_drm *priv) > > VIU_OSD_FIFO_LIMITS(2); /* fifo_lim: 2*16=32 */ > > > > if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) > > - reg |= meson_viu_osd_burst_length_reg(32); > > + reg |= VIU_OSD_BURST_LENGTH_32; > > else > > - reg |= meson_viu_osd_burst_length_reg(64); > > + reg |= VIU_OSD_BURST_LENGTH_64; > > > > writel_relaxed(reg, priv->io_base + _REG(VIU_OSD1_FIFO_CTRL_STAT)); > > writel_relaxed(reg, priv->io_base + _REG(VIU_OSD2_FIFO_CTRL_STAT)); > > > > Thanks, > Will run some tests ! Does this fix/improve anything for you? On the 32-bit SoCs kmscube is not smooth (neither on the CVBS nor on the HDMI output) with a burst length of 24 (which was the old "accidentally used" value). Martin
Re: [PATCH v2 net-next 3/3] ptp: ptp_clockmatrix: Add adjphase() to support PHC write phase mode.
On Fri, May 01, 2020 at 11:35:38PM -0400, vincent.cheng...@renesas.com wrote: > From: Vincent Cheng > > Add idtcm_adjphase() to support PHC write phase mode. > > Signed-off-by: Vincent Cheng Acked-by: Richard Cochran
Re: [PATCH v2 net-next 1/3] ptp: Add adjphase function to support phase offset control.
On Fri, May 01, 2020 at 11:35:36PM -0400, vincent.cheng...@renesas.com wrote: > From: Vincent Cheng > > Adds adjust phase function to take advantage of a PHC > clock's hardware filtering capability that uses phase offset > control word instead of frequency offset control word. > > Signed-off-by: Vincent Cheng Reviewed-by: Richard Cochran
Re: [v4] checkpatch: add support to check 'Fixes:' tag format
>> Will the tolerance (and support) grow for such quotation character >> alternatives? > > No. Would you prefer to achieve a restrictive data format description? >> * Which formula do you propose for the length calculation? > > None. I imagine that such a view can increase the probability for confusion. Regards, Markus
Re: [PATCH v4] checkpatch: add support to check 'Fixes:' tag format
On Sat, 2020-05-02 at 21:40 +0200, Markus Elfring wrote: > > The check doesn't support below formats and it will emit diagnostics info > > for them: [] > Will the tolerance (and support) grow for such quotation character > alternatives? No. > Does this information indicate a need to split possible changes into > separate update steps? No. > * Which formula do you propose for the length calculation? None.
[GIT PULL] Power management fixes for v5.7-rc4
Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-5.7-rc4 with top-most commit a53839963ee22470a716de665bca39d2dae63c27 Merge branches 'pm-cpufreq' and 'pm-sleep' on top of commit 6a8b55ed4056ea5559ebe4f6a4b247f627870d4c Linux 5.7-rc3 to receive power management fixes for 5.7-rc4. These prevent the intel_pstate driver from printing excessive diagnostic messages in some cases (Chris Wilson), make the hibernation restore kernel freeze kernel threads as well as user space tasks (Dexuan Cui) and fix the ACPI device PM disagnostic messages to include the correct power state name (Kai-Heng Feng). Thanks! --- Chris Wilson (1): cpufreq: intel_pstate: Only mention the BIOS disabling turbo mode once Dexuan Cui (1): PM: hibernate: Freeze kernel threads in software_resume() Kai-Heng Feng (1): PM: ACPI: Output correct message on target power state --- drivers/acpi/device_pm.c | 4 ++-- drivers/cpufreq/intel_pstate.c | 2 +- kernel/power/hibernate.c | 7 +++ 3 files changed, 10 insertions(+), 3 deletions(-)
[PATCH] media: s5p-mfc: set V4L2_BUF_FLAG_LAST flag on final buffer
From: Andriy Gelman As per V4L2 api, the final buffer should set V4L2_BUF_FLAG_LAST flag. Signed-off-by: Andriy Gelman --- drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 5c2a23b953a4..b3d9b3a523fe 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -614,6 +614,7 @@ static void s5p_mfc_handle_stream_complete(struct s5p_mfc_ctx *ctx) list_del(_entry->list); ctx->dst_queue_cnt--; vb2_set_plane_payload(_entry->b->vb2_buf, 0, 0); + mb_entry->b->flags |= V4L2_BUF_FLAG_LAST; vb2_buffer_done(_entry->b->vb2_buf, VB2_BUF_STATE_DONE); } -- 2.25.1
Re: [PATCH v4] checkpatch: add support to check 'Fixes:' tag format
> The check doesn't support below formats and it will emit diagnostics info for
> them:
…
> Fixes: ba35f8588f47 (“ipvlan: Defer multicast / broadcast processing to a
> work-queue”)
…
> Fixes: 03f6fc6de919 ('ASoC: rt5682: Add the soundwire support')
Will the tolerance (and support) grow for such quotation character alternatives?
> Note: this patch also fixes double quotation mark issue for normal git
> commit description, and now it supports double quotation mark in
> title line, for example:
> Commit e33e2241e272 ("Revert "cfg80211: Use 5MHz bandwidth by default
> when checking usable channels"")
Do you care to achieve a safe data format description also for this use case?
> Note: this patch also adds diagnostics info support for normal git commit
> description format check.
Does this information indicate a need to split possible changes into
separate update steps?
> + $diagnostics .= "Missing a pair of parentheses
> '()' or a pair of double quotation marks (\"\").\n";
Can such a message trigger any more thoughts and development ideas?
> + $diagnostics .= "The title is too
> abbreviated, at least half of orignial commit title is necessary.\n";
* Please avoid a typo in this message.
* Which formula do you propose for the length calculation?
Regards,
Markus
[PATCH 0/2] ALSA: line6: hwdep: add support for poll and non-blocking read
This series adds support for polling and non-blocking read for hwdep interface. This allows apps to listen to HW events without using busy loop. Example of app that uses hwdep interface for POD HD500 can be found here: https://github.com/anarsoul/line6_hwdep_test Vasily Khoruzhick (2): ALSA: line6: hwdep: add support for O_NONBLOCK opening mode ALSA: line6: Add poll callback for hwdep sound/usb/line6/driver.c | 20 sound/usb/line6/driver.h | 1 + 2 files changed, 21 insertions(+) -- 2.26.2
[PATCH 2/2] ALSA: line6: Add poll callback for hwdep
At least POD HD500 uses message-based communication, both sides can
send messages. Add poll callback so application can wait for device
messages without using busy loop.
Signed-off-by: Vasily Khoruzhick
---
sound/usb/line6/driver.c | 16
1 file changed, 16 insertions(+)
diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 86adf87d57f0..7629116f570e 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -630,11 +630,27 @@ line6_hwdep_write(struct snd_hwdep *hwdep, const char
__user *data, long count,
return rv;
}
+static __poll_t
+line6_hwdep_poll(struct snd_hwdep *hwdep, struct file *file, poll_table *wait)
+{
+ __poll_t rv;
+ struct usb_line6 *line6 = hwdep->private_data;
+
+ poll_wait(file, >messages.wait_queue, wait);
+
+ mutex_lock(>messages.read_lock);
+ rv = kfifo_len(>messages.fifo) == 0 ? 0 : EPOLLIN | EPOLLRDNORM;
+ mutex_unlock(>messages.read_lock);
+
+ return rv;
+}
+
static const struct snd_hwdep_ops hwdep_ops = {
.open= line6_hwdep_open,
.release = line6_hwdep_release,
.read= line6_hwdep_read,
.write = line6_hwdep_write,
+ .poll= line6_hwdep_poll,
};
/* Insert into circular buffer */
--
2.26.2
[PATCH 1/2] ALSA: line6: hwdep: add support for O_NONBLOCK opening mode
Currently line6 hwdep interface ignores O_NONBLOCK flag when
opening device and it renders it somewhat useless when using poll.
Check for O_NONBLOCK flag when opening device and don't block read()
if it is set.
Signed-off-by: Vasily Khoruzhick
---
sound/usb/line6/driver.c | 4
sound/usb/line6/driver.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 4f096685ed65..86adf87d57f0 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -550,6 +550,7 @@ static int line6_hwdep_open(struct snd_hwdep *hw, struct
file *file)
/* NOTE: hwdep layer provides atomicity here */
line6->messages.active = 1;
+ line6->messages.nonblock = file->f_flags & O_NONBLOCK ? 1 : 0;
return 0;
}
@@ -579,6 +580,9 @@ line6_hwdep_read(struct snd_hwdep *hwdep, char __user *buf,
long count,
while (kfifo_len(>messages.fifo) == 0) {
mutex_unlock(>messages.read_lock);
+ if (line6->messages.nonblock)
+ return -EAGAIN;
+
rv = wait_event_interruptible(
line6->messages.wait_queue,
kfifo_len(>messages.fifo) != 0);
diff --git a/sound/usb/line6/driver.h b/sound/usb/line6/driver.h
index e5e572ed5f30..1a4e3700c80c 100644
--- a/sound/usb/line6/driver.h
+++ b/sound/usb/line6/driver.h
@@ -163,6 +163,7 @@ struct usb_line6 {
struct mutex read_lock;
wait_queue_head_t wait_queue;
unsigned int active:1;
+ unsigned int nonblock:1;
STRUCT_KFIFO_REC_2(LINE6_BUFSIZE_LISTEN *
LINE6_RAW_MESSAGES_MAXCOUNT)
fifo;
} messages;
--
2.26.2
Re: [PATCH] bpf: Tweak BPF jump table optimizations for objtool compatibility
On Fri, May 01, 2020 at 08:06:22PM -0700, Alexei Starovoitov wrote:
> On Fri, May 01, 2020 at 02:56:17PM -0500, Josh Poimboeuf wrote:
> > On Fri, May 01, 2020 at 12:40:53PM -0700, Alexei Starovoitov wrote:
> > > On Fri, May 01, 2020 at 02:22:04PM -0500, Josh Poimboeuf wrote:
> > > > On Fri, May 01, 2020 at 12:09:30PM -0700, Alexei Starovoitov wrote:
> > > > > On Thu, Apr 30, 2020 at 02:07:43PM -0500, Josh Poimboeuf wrote:
> > > > > > Objtool decodes instructions and follows all potential code branches
> > > > > > within a function. But it's not an emulator, so it doesn't track
> > > > > > register values. For that reason, it usually can't follow
> > > > > > intra-function indirect branches, unless they're using a jump table
> > > > > > which follows a certain format (e.g., GCC switch statement jump
> > > > > > tables).
> > > > > >
> > > > > > In most cases, the generated code for the BPF jump table looks a lot
> > > > > > like a GCC jump table, so objtool can follow it. However, with
> > > > > > RETPOLINE=n, GCC keeps the jump table address in a register, and
> > > > > > then
> > > > > > does 160+ indirect jumps with it. When objtool encounters the
> > > > > > indirect
> > > > > > jumps, it can't tell which jump table is being used (or even whether
> > > > > > they might be sibling calls instead).
> > > > > >
> > > > > > This was fixed before by disabling an optimization in
> > > > > > ___bpf_prog_run(),
> > > > > > using the "optimize" function attribute. However, that attribute
> > > > > > is bad
> > > > > > news. It doesn't append options to the command-line arguments.
> > > > > > Instead
> > > > > > it starts from a blank slate. And according to recent GCC
> > > > > > documentation
> > > > > > it's not recommended for production use. So revert the previous
> > > > > > fix:
> > > > > >
> > > > > > 3193c0836f20 ("bpf: Disable GCC -fgcse optimization for
> > > > > > ___bpf_prog_run()")
> > > > > >
> > > > > > With that reverted, solve the original problem in a different way by
> > > > > > getting rid of the "goto select_insn" indirection, and instead just
> > > > > > goto
> > > > > > the jump table directly. This simplifies the code a bit and helps
> > > > > > GCC
> > > > > > generate saner code for the jump table branches, at least in the
> > > > > > RETPOLINE=n case.
> > > > > >
> > > > > > But, in the RETPOLINE=y case, this simpler code actually causes GCC
> > > > > > to
> > > > > > generate far worse code, ballooning the function text size by +40%.
> > > > > > So
> > > > > > leave that code the way it was. In fact Alexei prefers to leave
> > > > > > *all*
> > > > > > the code the way it was, except where needed by objtool. So even
> > > > > > non-x86 RETPOLINE=n code will continue to have "goto select_insn".
> > > > > >
> > > > > > This stuff is crazy voodoo, and far from ideal. But it works for
> > > > > > now.
> > > > > > Eventually, there's a plan to create a compiler plugin for
> > > > > > annotating
> > > > > > jump tables. That will make this a lot less fragile.
> > > > >
> > > > > I don't like this commit log.
> > > > > Here you're saying that the code recognized by objtool is sane and
> > > > > good
> > > > > whereas well optimized gcc code is somehow voodoo and bad.
> > > > > That is just wrong.
> > > >
> > > > I have no idea what you're talking about.
> > > >
> > > > Are you saying that ballooning the function text size by 40% is well
> > > > optimized GCC code? It seems like a bug to me. That's the only place I
> > > > said anything bad about GCC code.
> > >
> > > It could be a bug, but did you benchmark the speed of interpreter ?
> > > Is it faster or slower with 40% more code ?
> > > Did you benchmark it on other archs ?
> >
> > I thought we were in agreement that 40% text growth is bad. Isn't that
> > why you wanted to keep 'goto select_insn' for the retpoline case?
>
> Let me see whether I got this right.
> In first the sentence above you're claiming that I've agreed that
> 'goto select_insn' is bad for retpoline case and in the second sentence
> you're saying that I wanted to keep it because it's bad?
> In other words you're saying I wanted bad code for retpoline case for
> some mischievous purpose?
> Do you really think so or just trolling?
I *never* said anything about 'goto select_insn' being bad for the
retpoline case.
GETTING RID OF IT is bad for the retpoline case, i.e. text explosion.
That's why (I thought) you wanted to keep it for the retpoline case.
Go back and read the words I've written instead of accusing me of
trolling... WTF.
> Let's look at the facts.
> I've applied your patch and the kernel crashed on the very first test in
> selftests/bpf which makes me believe that you only compile tested it.
Yes, that was a dumb mistake. But to be fair, I asked you about that
change, and you said it was ok:
https://lkml.kernel.org/r/20200430042400.45vvqx4ocwwog...@ast-mbp.dhcp.thefacebook.com
Now I see it's obviously a
Re: [RFC PATCH v11 6/9] media: tegra: Add Tegra210 Video input driver
On 5/2/20 10:04 AM, Sowjanya Komatineni wrote:
On 5/2/20 9:55 AM, Sowjanya Komatineni wrote:
On 5/2/20 9:14 AM, Sowjanya Komatineni wrote:
On 5/2/20 9:03 AM, Sowjanya Komatineni wrote:
On 5/2/20 8:38 AM, Sowjanya Komatineni wrote:
On 5/2/20 8:16 AM, Dmitry Osipenko wrote:
02.05.2020 06:55, Sowjanya Komatineni пишет:
On 5/1/20 8:39 PM, Sowjanya Komatineni wrote:
On 5/1/20 2:05 PM, Sowjanya Komatineni wrote:
On 5/1/20 1:58 PM, Sowjanya Komatineni wrote:
On 5/1/20 1:44 PM, Sowjanya Komatineni wrote:
On 5/1/20 11:03 AM, Sowjanya Komatineni wrote:
On 4/30/20 4:33 PM, Sowjanya Komatineni wrote:
On 4/30/20 4:14 PM, Sowjanya Komatineni wrote:
And in this case synchronization between start/finish
threads should be
needed in regards to freezing.
Was thinking to have counter to track outstanding frame
w.r.t single shot issue b/w start and finish and
allow to
freeze only when no outstanding frames in process.
This will make sure freeze will not happen when any
buffers
are in progress
Note that this could be a wrong assumption, I'm not
closely familiar
with how freezer works.
kthread_start can unconditionally allow try_to_freeze
before
start of frame capture
We can compute captures inflight w.r.t single shot
issued
during capture start and finished frames by
kthread_finish
and allow kthread_finish to freeze only when captures
inflight is 0.
This allows freeze to happen b/w frames but not in
middle of
frame
will have caps inflight check in v12 to allow freeze finish
thread only when no captures are in progress
try_to_freeze() returns thread frozen state and looks
like we
can use this in kthread finish to allow finish thread to
freeze
only when kthread_start is already frozen and no buffers in
progress/initiated for capture.
chan->capture_frozen holds frozen state returned from
try_to_freeze() in start kthread
chan->capture_reqs increments after every single shot issued.
static int chan_capture_kthread_finish(void *data)
{
struct tegra_vi_channel *chan = data;
struct tegra_channel_buffer *buf;
int caps_inflight;
set_freezable();
while (1) {
wait_event_interruptible(chan->done_wait,
!list_empty(>done) ||
kthread_should_stop());
/* dequeue buffers and finish capture */
buf = dequeue_buf_done(chan);
while (buf) {
tegra_channel_capture_done(chan, buf);
buf = dequeue_buf_done(chan);
}
if (kthread_should_stop())
break;
caps_inflight = chan->capture_reqs - chan->sequence;
if (chan->capture_frozen && !caps_inflight)
try_to_freeze();
}
return 0;
}
Freezing happens prior to suspend() during suspend entry
and when
we implement suspend/resume during suspend we stop
streaming where
we stop threads anyway.
So, was thinking why we need these threads freezable here?
Hi Dmitry,
Did some testing and below are latest observation and fix I
tested.
wait_event_interruptible() uses schedule() which blocks the
freezer.
When I do suspend while keeping streaming active in
background, I
see freezing of these threads fail and call trace shows
__schedule
-> __switch_to from these kthreads.
wait_event_freezable() uses freezable_schedule() which
should not
block the freezer but we can't use this here as we need
conditional
try_to_freeze().
So, doing below sequence works where we set PF_FREEZER_SKIP
flag
thru freezer_not_count() before wait_event which calls
schedule()
and remove PF_FREEZER_SKIP after schedule allows
try_to_freeze to
work and also conditional try_to_freeze below prevents freezing
thread in middle of capture.
while (1) {
freezer_not_count()
wait_event_interruptible()
freezer_count()
...
...
if (chan->capture_frozen && !caps_inflight)
try_to_freeze()
}
Please comment if you agree with above sequence. Will
include this
in v12.
sorry, freezer_count() does try_to_freeze after clearing skip
flag.
So, dont think we can use this as we need conditional
try_to_freeze.
Please ignore above sequence.
Or probably we can take closer look on this later when we add
suspend/resume support as it need more testing as well.
As this is initial series which has TPG only I think we
shouldn't
get blocked on this now. Series-2 and 3 will be for sensor
support
and on next series when we add suspend/resume will look into
this.
When freeze activity starts and in case if finish thread
freezes prior
to start thread issuing capture, its the VI hardware writes
data to
the allocated buffer address.
finish thread just checks for the event from the hardware and
we don't
handle/process directly on memory in this driver.
So even we freeze done thread when single shot is issued frame
buffer
gets updated.
In case if capture thread is frozen there will not buffers
queued to
process by finish thread. So, this will not be an issue.
So, probably we don't need to do conditional
Re: [PATCH] checkpatch: fix can't check for too long invalid commit id
On Sun, 2020-05-03 at 02:50 +0800, Wang YanQing wrote:
> The current UNKNOWN_COMMIT_ID doesn't check for 41+ length commit id,
> and although GIT_COMMIT_ID will check for 41+ length commit id, but
> it willn't warn anything about it due to 41+ length commit will never
> be defined.
>
> This patch moves the unknown commit id check for normal commit description
> to GIT_COMMIT_ID, and uses ERROR instead of WARN, because unknown commit
> id is total useless to track change history in changelog, it deserves the
> ERROR.
>
> Signed-off-by: Wang YanQing
Hi again. Trivial notes:
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -2865,8 +2865,18 @@ sub process {
> ($id, $description) = git_commit_info($orig_commit,
> $id, $orig_desc);
>
> + if (!defined($id)) {
> + if ($long) {
> + ERROR("GIT_COMMIT_ID",
> + "Unknown commit id '$orig_commit' is too
> long, maybe misspelled?\n" . $herecurr);
checkpatch always uses tab indentation.
Please convert from 4 spaces to 1
tab and reindent the rest.
"misspelled" word choice may not be the best here as a
SHA-1 isn't really something that is spelled.
Perhaps something like:
"Invalid commit id '$orig_commit' length '" . length($orig_commit) . "'
exceeds allowed maximum of 40\n",
Though maybe a recommended maximum of some constant should be used.
my $recommended_sha_length = 12;
> @@ -2969,7 +2979,7 @@ sub process {
> }
>
> # check for invalid commit id
> - if ($in_commit_log && $line =~
> /(^fixes:|\bcommit)\s+([0-9a-f]{6,40})\b/i) {
> + if ($in_commit_log && $line =~
> /(^fixes:)\s+([0-9a-f]{6,40})\b/i) {
Likely this capture group around Fixes: isn't necessary any more.
> my $id;
> my $description;
> ($id, $description) = git_commit_info($2, undef, undef);
$1 ?
Re: [PATCH v4 4/4] gpio: xilinx: Utilize for_each_set_clump macro
On Sun, May 03, 2020 at 12:21:54AM +0530, Syed Nayyar Waris wrote:
> This patch reimplements the xgpio_set_multiple function in
> drivers/gpio/gpio-xilinx.c to use the new for_each_set_clump macro.
> Instead of looping for each bit in xgpio_set_multiple
> function, now we can check each channel at a time and save cycles.
>
> Cc: Linus Walleij
> Cc: Bartosz Golaszewski
> Cc: Michal Simek
> Signed-off-by: Syed Nayyar Waris
> Signed-off-by: William Breathitt Gray
> ---
> Changes in v4:
> - Minor change: Hardcode value for better code readability.
>
> Changes in v3:
> - No change.
>
> Changes in v2:
> - No change.
>
> drivers/gpio/gpio-xilinx.c | 64 --
> 1 file changed, 34 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> index 67f9f82e0db0..67c5eeaf1bb9 100644
> --- a/drivers/gpio/gpio-xilinx.c
> +++ b/drivers/gpio/gpio-xilinx.c
> @@ -136,39 +136,43 @@ static void xgpio_set(struct gpio_chip *gc, unsigned
> int gpio, int val)
> static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
> unsigned long *bits)
> {
> - unsigned long flags;
> + unsigned long flags[2];
> struct xgpio_instance *chip = gpiochip_get_data(gc);
> - int index = xgpio_index(chip, 0);
> - int offset, i;
> -
> - spin_lock_irqsave(>gpio_lock[index], flags);
> -
> - /* Write to GPIO signals */
> - for (i = 0; i < gc->ngpio; i++) {
> - if (*mask == 0)
> - break;
> - /* Once finished with an index write it out to the register */
> - if (index != xgpio_index(chip, i)) {
> - xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> -index * XGPIO_CHANNEL_OFFSET,
> -chip->gpio_state[index]);
> - spin_unlock_irqrestore(>gpio_lock[index], flags);
> - index = xgpio_index(chip, i);
> - spin_lock_irqsave(>gpio_lock[index], flags);
> - }
> - if (__test_and_clear_bit(i, mask)) {
> - offset = xgpio_offset(chip, i);
> - if (test_bit(i, bits))
> - chip->gpio_state[index] |= BIT(offset);
> - else
> - chip->gpio_state[index] &= ~BIT(offset);
> - }
> + u32 *const state = chip->gpio_state;
> + unsigned int *const width = chip->gpio_width;
> + const unsigned long state_size = 32;
> + const unsigned long total_state_bits = state_size * 2;
Hello Syed,
I don't think there's much need for these two variables either. You can
remove the state_size and total_state_bits variables, and instead inline
32 and 64 directly in your code below.
William Breathitt Gray
> + unsigned long offset, clump;
> + size_t index;
> +
> + DECLARE_BITMAP(old, 64);
> + DECLARE_BITMAP(new, 64);
> + DECLARE_BITMAP(changed, 64);
> +
> + spin_lock_irqsave(>gpio_lock[0], flags[0]);
> + spin_lock_irqsave(>gpio_lock[1], flags[1]);
> +
> + bitmap_set_value(old, state[0], 0, width[0]);
> + bitmap_set_value(old, state[1], width[0], width[1]);
> + bitmap_replace(new, old, bits, mask, gc->ngpio);
> +
> + bitmap_set_value(old, state[0], 0, state_size);
> + bitmap_set_value(old, state[1], state_size, state_size);
> + state[0] = bitmap_get_value(new, 0, width[0]);
> + state[1] = bitmap_get_value(new, width[0], width[1]);
> + bitmap_set_value(new, state[0], 0, state_size);
> + bitmap_set_value(new, state[1], state_size, state_size);
> + bitmap_xor(changed, old, new, total_state_bits);
> +
> + for_each_set_clump(offset, clump, changed, total_state_bits,
> state_size) {
> + index = offset / state_size;
> + xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> + index * XGPIO_CHANNEL_OFFSET,
> + state[index]);
> }
>
> - xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> -index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]);
> -
> - spin_unlock_irqrestore(>gpio_lock[index], flags);
> + spin_unlock_irqrestore(>gpio_lock[1], flags[1]);
> + spin_unlock_irqrestore(>gpio_lock[0], flags[0]);
> }
>
> /**
> --
> 2.26.2
>
signature.asc
Description: PGP signature
Re: [MPTCP] [PATCH 1/7] mptcp: use SHA256_BLOCK_SIZE, not SHA_MESSAGE_BYTES
Hi Eric, On 02/05/2020 20:24, Eric Biggers wrote: From: Eric Biggers In preparation for naming the SHA-1 stuff in properly and moving it to a more appropriate header, fix the HMAC-SHA256 code in mptcp_crypto_hmac_sha() to use SHA256_BLOCK_SIZE instead of "SHA_MESSAGE_BYTES" which is actually the SHA-1 block size. (Fortunately these are both 64 bytes, so this wasn't a "real" bug...) Good catch! I guess it was left when switching from SHA-1 to SHA-256 in 65492c5a6ab5 (mptcp: move from sha1 (v0) to sha256 (v1)). For MPTCP related code, it looks good to me, thank you for this! Reviewed-by: Matthieu Baerts -- Matthieu Baerts | R Engineer matthieu.bae...@tessares.net Tessares SA | Hybrid Access Solutions www.tessares.net 1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
[PATCH] checkpatch: fix can't check for too long invalid commit id
The current UNKNOWN_COMMIT_ID doesn't check for 41+ length commit id,
and although GIT_COMMIT_ID will check for 41+ length commit id, but
it willn't warn anything about it due to 41+ length commit will never
be defined.
This patch moves the unknown commit id check for normal commit description
to GIT_COMMIT_ID, and uses ERROR instead of WARN, because unknown commit
id is total useless to track change history in changelog, it deserves the
ERROR.
Signed-off-by: Wang YanQing
---
After this patch, in another patch 'checkpatch: add support to check 'Fixes:'
tag format',
I will delete UNKNOWN_COMMIT_ID, because we don't need it anymore after
GIT_COMMIT_ID could
do the same check as UNKNOWN_COMMIT_ID for 'Fixes:' tag.
scripts/checkpatch.pl | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 23a001a..143bb43 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2865,8 +2865,18 @@ sub process {
($id, $description) = git_commit_info($orig_commit,
$id, $orig_desc);
+ if (!defined($id)) {
+ if ($long) {
+ ERROR("GIT_COMMIT_ID",
+ "Unknown commit id '$orig_commit' is too
long, maybe misspelled?\n" . $herecurr);
+ } else {
+ ERROR("GIT_COMMIT_ID",
+ "Unknown commit id '$orig_commit', maybe
rebased or not pulled?\n" . $herecurr);
+ }
+ }
+
if (defined($id) &&
- ($short || $long || $space || $case || ($orig_desc
ne $description) || !$hasparens)) {
+ ($short || $space || $case || ($orig_desc ne
$description) || !$hasparens)) {
ERROR("GIT_COMMIT_ID",
"Please use git commit description style
'commit <12+ chars of sha1> (\"\")' - ie: '${init_char}ommit $id
(\"$description\")'\n" . $herecurr);
}
@@ -2969,7 +2979,7 @@ sub process {
}
# check for invalid commit id
- if ($in_commit_log && $line =~
/(^fixes:|\bcommit)\s+([0-9a-f]{6,40})\b/i) {
+ if ($in_commit_log && $line =~
/(^fixes:)\s+([0-9a-f]{6,40})\b/i) {
my $id;
my $description;
($id, $description) = git_commit_info($2, undef, undef);
--
1.8.5.6.2.g3d8a54e.dirty
[PATCH v4] checkpatch: add support to check 'Fixes:' tag format
According to submitting-patches.rst, 'Fixes:' tag has a little
stricter condition about the one line summary than normal git
commit description:
“...
Do not split the tag across multiple lines, tags are exempt from
the "wrap at 75 columns" rule in order to simplify parsing scripts
...”
And there is no sanity check for 'Fixes:' tag format in checkpatch
the same as GIT_COMMIT_ID for git commit description, so let's expand
the GIT_COMMIT_ID to add 'Fixes:' tag format check support.
The check supports below formats:
Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of
pages it actually freed")
Fixes: 85f7cd3a2aad ("Revert "media: Kconfig: better support hybrid TV
devices"")
Fixes: 878520ac45f9 ("ext4: save the error code which triggered...")
Fixes: 878520ac45f9 ("ext4: save the error code which triggered")
Fixes: 277f27e2f277 ("SUNRPC/cache: Allow garbage collection ... ")
The check doesn't support below formats and it will emit diagnostics info for
them:
Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface"
Fixes: 6c73698904aa pinctrl: qcom: Introduce readl/writel accessors
Fixes: 3fd6e7d9a146 (ASoC: tas571x: New driver for TI TAS571x power amplifiers)
Fixes: 55697cbb44e4 ("arm64: dts: renesas: r8a779{65,80,90}: Add IPMMU devices
nodes)
Fixes: ba35f8588f47 (“ipvlan: Defer multicast / broadcast processing to a
work-queue”)
Fixes: cd758a9b57ee "KVM: PPC: Book3S HV: Use __gfn_to_pfn_memslot in HPT page
fault handler"
Fixes: 9b1640686470 ("scsi: lpfc: Fix use-after-free mailbox cmd
completion")
Fixes: 03f6fc6de919 ('ASoC: rt5682: Add the soundwire support')
Because after GIT_COMMIT_ID supports 'Fixes:' tag format check, it could do
the same check as the UNKNOWN_COMMIT_ID, so we don't need UNKNOWN_COMMIT_ID
anymore and I decide to delete it.
Note: this patch also fixes double quotation mark issue for normal git
commit description, and now it supports double quotation mark in
title line, for example:
Commit e33e2241e272 ("Revert "cfg80211: Use 5MHz bandwidth by default
when checking usable channels"")
Note: this patch also adds diagnostics info support for normal git commit
description format check.
Based on original patch by Joe Perches
Link:
https://lore.kernel.org/lkml/40bfc40958fca6e2cc9b86101153aa0715fac4f7.ca...@perches.com/
Signed-off-by: Wang YanQing
---
v4:
1: Add diagnostics info support, suggested by Joe Perches and Markus Elfring.
2: Delete UNKNOWN_COMMIT_ID and do the check in GIT_COMMIT_ID.
v3:
1: Fix a bug in short title line support.
v2:
1: Add support for double quotation mark in title line, suggested by Markus
Elfring.
2: Add support for short title line with/without ellipsis.
3: Add supported format examples and unsupported format examples in changelog.
4: Fix a little wording issue in changelog , suggested by Markus Elfring.
scripts/checkpatch.pl | 115 +-
1 file changed, 85 insertions(+), 30 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 143bb43..b5768e0 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2818,48 +2818,93 @@ sub process {
$line !~
/^\s*(?:Link|Patchwork|http|https|BugLink|base-commit):/i &&
$line !~ /^This reverts commit [0-9a-f]{7,40}/ &&
($line =~ /\bcommit\s+[0-9a-f]{5,}\b/i ||
+$line =~ /\bfixes:\s+[0-9a-f]{5,}\b/i ||
($line =~ /(?:\s|^)[0-9a-f]{12,40}(?:[\s"'\(\[]|$)/i &&
- $line !~ /[\<\[][0-9a-f]{12,40}[\>\]]/i &&
- $line !~ /\bfixes:\s*[0-9a-f]{12,40}/i))) {
+ $line !~ /[\<\[][0-9a-f]{12,40}[\>\]]/i))) {
my $init_char = "c";
my $orig_commit = "";
+ my $prefix = "commit";
+ my $prefix_case = "[Cc]ommit";
my $short = 1;
my $long = 0;
my $case = 1;
my $space = 1;
my $hasdesc = 0;
- my $hasparens = 0;
+ my $has_parens_and_dqm = 0; # Double quotation mark
+ my $hasprefix = 1;
my $id = '0123456789ab';
my $orig_desc = "commit description";
my $description = "";
+ my $acrosslines = 0;
+ my $title = "title line";
+ my $desc_mismatch = 0;
+ my $diagnostics = "Diagnostics info:\n";
- if ($line =~ /\b(c)ommit\s+([0-9a-f]{5,})\b/i) {
+ if ($line =~ /\b(f)ixes:\s+([0-9a-f]{5,})\b/i) {
+ $init_char = $1;
+ $orig_commit = lc($2);
+ $prefix = "Fixes:";
+
[PATCH v4 4/4] gpio: xilinx: Utilize for_each_set_clump macro
This patch reimplements the xgpio_set_multiple function in
drivers/gpio/gpio-xilinx.c to use the new for_each_set_clump macro.
Instead of looping for each bit in xgpio_set_multiple
function, now we can check each channel at a time and save cycles.
Cc: Linus Walleij
Cc: Bartosz Golaszewski
Cc: Michal Simek
Signed-off-by: Syed Nayyar Waris
Signed-off-by: William Breathitt Gray
---
Changes in v4:
- Minor change: Hardcode value for better code readability.
Changes in v3:
- No change.
Changes in v2:
- No change.
drivers/gpio/gpio-xilinx.c | 64 --
1 file changed, 34 insertions(+), 30 deletions(-)
diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index 67f9f82e0db0..67c5eeaf1bb9 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -136,39 +136,43 @@ static void xgpio_set(struct gpio_chip *gc, unsigned int
gpio, int val)
static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
unsigned long *bits)
{
- unsigned long flags;
+ unsigned long flags[2];
struct xgpio_instance *chip = gpiochip_get_data(gc);
- int index = xgpio_index(chip, 0);
- int offset, i;
-
- spin_lock_irqsave(>gpio_lock[index], flags);
-
- /* Write to GPIO signals */
- for (i = 0; i < gc->ngpio; i++) {
- if (*mask == 0)
- break;
- /* Once finished with an index write it out to the register */
- if (index != xgpio_index(chip, i)) {
- xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
- index * XGPIO_CHANNEL_OFFSET,
- chip->gpio_state[index]);
- spin_unlock_irqrestore(>gpio_lock[index], flags);
- index = xgpio_index(chip, i);
- spin_lock_irqsave(>gpio_lock[index], flags);
- }
- if (__test_and_clear_bit(i, mask)) {
- offset = xgpio_offset(chip, i);
- if (test_bit(i, bits))
- chip->gpio_state[index] |= BIT(offset);
- else
- chip->gpio_state[index] &= ~BIT(offset);
- }
+ u32 *const state = chip->gpio_state;
+ unsigned int *const width = chip->gpio_width;
+ const unsigned long state_size = 32;
+ const unsigned long total_state_bits = state_size * 2;
+ unsigned long offset, clump;
+ size_t index;
+
+ DECLARE_BITMAP(old, 64);
+ DECLARE_BITMAP(new, 64);
+ DECLARE_BITMAP(changed, 64);
+
+ spin_lock_irqsave(>gpio_lock[0], flags[0]);
+ spin_lock_irqsave(>gpio_lock[1], flags[1]);
+
+ bitmap_set_value(old, state[0], 0, width[0]);
+ bitmap_set_value(old, state[1], width[0], width[1]);
+ bitmap_replace(new, old, bits, mask, gc->ngpio);
+
+ bitmap_set_value(old, state[0], 0, state_size);
+ bitmap_set_value(old, state[1], state_size, state_size);
+ state[0] = bitmap_get_value(new, 0, width[0]);
+ state[1] = bitmap_get_value(new, width[0], width[1]);
+ bitmap_set_value(new, state[0], 0, state_size);
+ bitmap_set_value(new, state[1], state_size, state_size);
+ bitmap_xor(changed, old, new, total_state_bits);
+
+ for_each_set_clump(offset, clump, changed, total_state_bits,
state_size) {
+ index = offset / state_size;
+ xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
+ index * XGPIO_CHANNEL_OFFSET,
+ state[index]);
}
- xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
- index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]);
-
- spin_unlock_irqrestore(>gpio_lock[index], flags);
+ spin_unlock_irqrestore(>gpio_lock[1], flags[1]);
+ spin_unlock_irqrestore(>gpio_lock[0], flags[0]);
}
/**
--
2.26.2
[PATCH v4 3/4] gpio: thunderx: Utilize for_each_set_clump macro
This patch reimplements the thunderx_gpio_set_multiple function in
drivers/gpio/gpio-thunderx.c to use the new for_each_set_clump macro.
Instead of looping for each bank in thunderx_gpio_set_multiple
function, now we can skip bank which is not set and save cycles.
Cc: Robert Richter
Cc: Linus Walleij
Cc: Bartosz Golaszewski
Signed-off-by: Syed Nayyar Waris
Signed-off-by: William Breathitt Gray
---
Changes in v4:
- Minor change: Hardcode value for better code readability.
Changes in v3:
- Change datatype of some variables from u64 to unsigned long
in function thunderx_gpio_set_multiple.
CHanges in v2:
- No change.
drivers/gpio/gpio-thunderx.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-thunderx.c b/drivers/gpio/gpio-thunderx.c
index 9f66deab46ea..58c9bb25a377 100644
--- a/drivers/gpio/gpio-thunderx.c
+++ b/drivers/gpio/gpio-thunderx.c
@@ -275,12 +275,15 @@ static void thunderx_gpio_set_multiple(struct gpio_chip
*chip,
unsigned long *bits)
{
int bank;
- u64 set_bits, clear_bits;
+ unsigned long set_bits, clear_bits, gpio_mask;
+ unsigned long offset;
+
struct thunderx_gpio *txgpio = gpiochip_get_data(chip);
- for (bank = 0; bank <= chip->ngpio / 64; bank++) {
- set_bits = bits[bank] & mask[bank];
- clear_bits = ~bits[bank] & mask[bank];
+ for_each_set_clump(offset, gpio_mask, mask, chip->ngpio, 64) {
+ bank = offset / 64;
+ set_bits = bits[bank] & gpio_mask;
+ clear_bits = ~bits[bank] & gpio_mask;
writeq(set_bits, txgpio->register_base + (bank * GPIO_2ND_BANK)
+ GPIO_TX_SET);
writeq(clear_bits, txgpio->register_base + (bank *
GPIO_2ND_BANK) + GPIO_TX_CLR);
}
--
2.26.2
[PATCH v4 2/4] lib/test_bitmap.c: Add for_each_set_clump test cases
The introduction of the generic for_each_set_clump macro need test
cases to verify the implementation. This patch adds test cases for
scenarios in which clump sizes are 8 bits, 24 bits, 30 bits and 6 bits.
The cases contain situations where clump is getting split at the word
boundary and also when zeroes are present in the start and middle of
bitmap.
Cc: Andy Shevchenko
Cc: Linus Walleij
Signed-off-by: Syed Nayyar Waris
Signed-off-by: William Breathitt Gray
---
Changes in v4:
- Use 'for' loop in test function of 'for_each_set_clump'.
Changes in v3:
- No Change.
Changes in v2:
- Unify different tests for 'for_each_set_clump'. Pass test data as
function parameters.
- Remove unnecessary bitmap_zero calls.
lib/test_bitmap.c | 141 ++
1 file changed, 141 insertions(+)
diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index 6b13150667f5..a2a1c411dd62 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -155,6 +155,38 @@ static bool __init __check_eq_clump8(const char *srcfile,
unsigned int line,
return true;
}
+static bool __init __check_eq_clump(const char *srcfile, unsigned int line,
+ const unsigned int offset,
+ const unsigned int size,
+ const unsigned long *const clump_exp,
+ const unsigned long *const clump,
+ const unsigned long clump_size)
+{
+ unsigned long exp;
+
+ if (offset >= size) {
+ pr_warn("[%s:%u] bit offset for clump out-of-bounds: expected
less than %u, got %u\n",
+ srcfile, line, size, offset);
+ return false;
+ }
+
+ exp = clump_exp[offset / clump_size];
+ if (!exp) {
+ pr_warn("[%s:%u] bit offset for zero clump: expected nonzero
clump, got bit offset %u with clump value 0",
+ srcfile, line, offset);
+ return false;
+ }
+
+ if (*clump != exp) {
+ pr_warn("[%s:%u] expected clump value of 0x%lX, got clump value
of 0x%lX",
+ srcfile, line, exp, *clump);
+ return false;
+ }
+
+ return true;
+}
+
+
#define __expect_eq(suffix, ...) \
({ \
int result = 0; \
@@ -172,6 +204,7 @@ static bool __init __check_eq_clump8(const char *srcfile,
unsigned int line,
#define expect_eq_pbl(...) __expect_eq(pbl, ##__VA_ARGS__)
#define expect_eq_u32_array(...) __expect_eq(u32_array, ##__VA_ARGS__)
#define expect_eq_clump8(...) __expect_eq(clump8, ##__VA_ARGS__)
+#define expect_eq_clump(...) __expect_eq(clump, ##__VA_ARGS__)
static void __init test_zero_clear(void)
{
@@ -588,6 +621,71 @@ static const unsigned char clump_exp[] __initconst = {
0x05, /* non-adjacent 2 bits set */
};
+static const unsigned long bitmap_test_data[] __initconst = {
+ 0x38000201,
+ 0x05ff0f38,
+ 0xeffedcba,
+ 0xabcd,
+ 0x00aa,
+ 0x00aa,
+ 0x00ff,
+ 0xaa00,
+ 0xff00,
+ 0x00aa,
+ 0x,
+ 0x,
+ 0x,
+ 0x0f00,
+ 0x0ac0,
+};
+
+static const unsigned long clump_exp1[] __initconst = {
+ 0x01, /* 1 bit set */
+ 0x02, /* non-edge 1 bit set */
+ 0x00, /* zero bits set */
+ 0x38, /* 3 bits set across 4-bit boundary */
+ 0x38, /* Repeated clump */
+ 0x0F, /* 4 bits set */
+ 0xFF, /* all bits set */
+ 0x05, /* non-adjacent 2 bits set */
+};
+
+static const unsigned long clump_exp2[] __initconst = {
+ 0xfedcba, /* 24 bits */
+ 0xabcdef,
+ 0xaa, /* Clump split between 2 words */
+ 0x00, /* zeroes in between */
+ 0xaa,
+ 0x00,
+ 0xff,
+ 0xaa,
+ 0x00,
+ 0xff,
+};
+
+static const unsigned long clump_exp3[] __initconst = {
+ 0x, /* starting with 0s*/
+ 0x, /* All 0s */
+ 0x,
+ 0x,
+ 0x3f0f, /* Non zero set */
+ 0x2aa80003,
+ 0x0aaa,
+ 0x3fc0,
+};
+
+static const unsigned long clump_exp4[] __initconst = {
+ 0x00,
+ 0x2b,
+};
+
+static const unsigned long * const clump_data[] __initconst = {
+ clump_exp1,
+ clump_exp2,
+ clump_exp3,
+ clump_exp4,
+};
+
static void __init test_for_each_set_clump8(void)
{
#define CLUMP_EXP_NUMBITS 64
@@ -610,6 +708,48 @@ static void __init test_for_each_set_clump8(void)
expect_eq_clump8(start, CLUMP_EXP_NUMBITS, clump_exp, );
}
+static void __init execute_for_each_set_clump_test(unsigned
[PATCH v4 1/4] bitops: Introduce the the for_each_set_clump macro
This macro iterates for each group of bits (clump) with set bits,
within a bitmap memory region. For each iteration, "start" is set to
the bit offset of the found clump, while the respective clump value is
stored to the location pointed by "clump". Additionally, the
bitmap_get_value and bitmap_set_value functions are introduced to
respectively get and set a value of n-bits in a bitmap memory region.
The n-bits can have any size less than or equal to BITS_PER_LONG.
Moreover, during setting value of n-bit in bitmap, if a situation arise
that the width of next n-bit is exceeding the word boundary, then it
will divide itself such that some portion of it is stored in that word,
while the remaining portion is stored in the next higher word. Similar
situation occurs while retrieving value of n-bits from bitmap.
Cc: Arnd Bergmann
Signed-off-by: Syed Nayyar Waris
Signed-off-by: William Breathitt Gray
---
Changes in v4:
- No change
Changes in v3:
- No change
Changes in v2:
- No change
include/asm-generic/bitops/find.h | 19 ++
include/linux/bitmap.h| 61 +++
include/linux/bitops.h| 13 +++
lib/find_bit.c| 14 +++
4 files changed, 107 insertions(+)
diff --git a/include/asm-generic/bitops/find.h
b/include/asm-generic/bitops/find.h
index 9fdf21302fdf..4e6600759455 100644
--- a/include/asm-generic/bitops/find.h
+++ b/include/asm-generic/bitops/find.h
@@ -97,4 +97,23 @@ extern unsigned long find_next_clump8(unsigned long *clump,
#define find_first_clump8(clump, bits, size) \
find_next_clump8((clump), (bits), (size), 0)
+/**
+ * find_next_clump - find next clump with set bits in a memory region
+ * @clump: location to store copy of found clump
+ * @addr: address to base the search on
+ * @size: bitmap size in number of bits
+ * @offset: bit offset at which to start searching
+ * @clump_size: clump size in bits
+ *
+ * Returns the bit offset for the next set clump; the found clump value is
+ * copied to the location pointed by @clump. If no bits are set, returns @size.
+ */
+extern unsigned long find_next_clump(unsigned long *clump,
+ const unsigned long *addr,
+ unsigned long size, unsigned long offset,
+ unsigned long clump_size);
+
+#define find_first_clump(clump, bits, size, clump_size) \
+ find_next_clump((clump), (bits), (size), 0, (clump_size))
+
#endif /*_ASM_GENERIC_BITOPS_FIND_H_ */
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 99058eb81042..7ab2c65fc964 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -75,7 +75,11 @@
* bitmap_from_arr32(dst, buf, nbits) Copy nbits from u32[] buf to
dst
* bitmap_to_arr32(buf, src, nbits)Copy nbits from buf to u32[]
dst
* bitmap_get_value8(map, start) Get 8bit value from map at
start
+ * bitmap_get_value(map, start, nbits)Get bit value of size
+ * 'nbits' from map at start
* bitmap_set_value8(map, value, start)Set 8bit value to map at start
+ * bitmap_set_value(map, value, start, nbits) Set bit value of size 'nbits'
+ * of map at start
*
* Note, bitmap_zero() and bitmap_fill() operate over the region of
* unsigned longs, that is, bits behind bitmap till the unsigned long
@@ -563,6 +567,34 @@ static inline unsigned long bitmap_get_value8(const
unsigned long *map,
return (map[index] >> offset) & 0xFF;
}
+/**
+ * bitmap_get_value - get a value of n-bits from the memory region
+ * @map: address to the bitmap memory region
+ * @start: bit offset of the n-bit value
+ * @nbits: size of value in bits
+ *
+ * Returns value of nbits located at the @start bit offset within the @map
+ * memory region.
+ */
+static inline unsigned long bitmap_get_value(const unsigned long *map,
+ unsigned long start,
+ unsigned long nbits)
+{
+ const size_t index = BIT_WORD(start);
+ const unsigned long offset = start % BITS_PER_LONG;
+ const unsigned long ceiling = roundup(start + 1, BITS_PER_LONG);
+ const unsigned long space = ceiling - start;
+ unsigned long value_low, value_high;
+
+ if (space >= nbits)
+ return (map[index] >> offset) & GENMASK(nbits - 1, 0);
+ else {
+ value_low = map[index] & BITMAP_FIRST_WORD_MASK(start);
+ value_high = map[index + 1] & BITMAP_LAST_WORD_MASK(start +
nbits);
+ return (value_low >> offset) | (value_high << space);
+ }
+}
+
/**
* bitmap_set_value8 - set an 8-bit value within a memory region
* @map: address to the bitmap memory region
@@ -579,6 +611,35 @@ static inline void bitmap_set_value8(unsigned long *map,
unsigned long value,
[PATCH v4 0/4] Introduce the for_each_set_clump macro
This patchset introduces a new generic version of for_each_set_clump. The previous version of for_each_set_clump8 used a fixed size 8-bit clump, but the new generic version can work with clump of any size but less than or equal to BITS_PER_LONG. The patchset utilizes the new macro in several GPIO drivers. The earlier 8-bit for_each_set_clump8 facilitated a for-loop syntax that iterates over a memory region entire groups of set bits at a time. For example, suppose you would like to iterate over a 32-bit integer 8 bits at a time, skipping over 8-bit groups with no set bit, where represents the current 8-bit group: Example:1010 00110011 First loop: 1010 Second loop:1010 00110011 Third loop: 00110011 Each iteration of the loop returns the next 8-bit group that has at least one set bit. But with the new for_each_set_clump the clump size can be different from 8 bits. Moreover, the clump can be split at word boundary in situations where word size is not multiple of clump size. Following are examples showing the working of new macro for clump sizes of 24 bits and 6 bits. Example 1: clump size: 24 bits, Number of clumps (or ports): 10 bitmap stores the bit information from where successive clumps are retrieved. /* bitmap memory region */ 0x00aaff00; /* Most significant bits */ 0xaaff; 0x00aa00aa; 0xabcdeffedcba; /* Least significant bits */ Different iterations of for_each_set_clump:- 'offset' is the bit position and 'clump' is the 24 bit clump from the above bitmap. Iteration first:offset: 0 clump: 0xfedcba Iteration second: offset: 24 clump: 0xabcdef Iteration third:offset: 48 clump: 0xaa Iteration fourth: offset: 96 clump: 0xaa Iteration fifth:offset: 144 clump: 0xff Iteration sixth:offset: 168 clump: 0xaa Iteration seventh: offset: 216 clump: 0xff Loop breaks because in the end the remaining bits (0x00aa) size was less than clump size of 24 bits. In above example it can be seen that in iteration third, the 24 bit clump that was retrieved was split between bitmap[0] and bitmap[1]. This example also shows that 24 bit zeroes if present in between, were skipped (preserving the previous for_each_set_macro8 behaviour). Example 2: clump size = 6 bits, Number of clumps (or ports) = 3. /* bitmap memory region */ 0x00aaff00; /* Most significant bits */ 0xaaff; 0x0f00; 0x0ac0; /* Least significant bits */ Different iterations of for_each_set_clump: 'offset' is the bit position and 'clump' is the 6 bit clump from the above bitmap. Iteration first:offset: 6 clump: 0x2b Loop breaks because 6 * 3 = 18 bits traversed in bitmap. Here 6 * 3 is clump size * no. of clumps. Changes in v4: - [Patch 2/4]: Use 'for' loop in test function of for_each_set_clump. - [Patch 3/4]: Minor change: Hardcode value for better code readability. - [Patch 4/4]: Minor change: Hardcode value for better code readability. Changes in v3: - [Patch 3/4]: Change datatype of some variables from u64 to unsigned long in function thunderx_gpio_set_multiple. CHanges in v2: - [Patch 2/4]: Unify different tests for 'for_each_set_clump'. Pass test data as function parameters. - [Patch 2/4]: Remove unnecessary bitmap_zero calls. Syed Nayyar Waris (4): bitops: Introduce the the for_each_set_clump macro lib/test_bitmap.c: Add for_each_set_clump test cases gpio: thunderx: Utilize for_each_set_clump macro gpio: xilinx: Utilize for_each_set_clump macro drivers/gpio/gpio-thunderx.c | 11 ++- drivers/gpio/gpio-xilinx.c| 64 +++--- include/asm-generic/bitops/find.h | 19 include/linux/bitmap.h| 61 + include/linux/bitops.h| 13 +++ lib/find_bit.c| 14 +++ lib/test_bitmap.c | 141 ++ 7 files changed, 289 insertions(+), 34 deletions(-) base-commit: 25c04a75f14fdc074d7dd1d6d40b49eddd0e66e7 -- 2.26.2
Re: [GIT PULL]: dmaengine fixes for v5.7-rc4
The pull request you sent on Sat, 2 May 2020 16:33:48 +0530: > git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-fix-5.7-rc4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ed6889db63d24600e523ac28fbece33201906611 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull NFS client bugfixes
The pull request you sent on Sat, 2 May 2020 13:35:02 +: > git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-5.7-4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/29a47f456d6213a3173722a098a3a18865ea4db3 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] iomap: bug fix for 5.7-rc3
The pull request you sent on Sat, 2 May 2020 10:08:01 -0700: > git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/iomap-5.7-fixes-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f66ed1ebbfde37631fba289f7c399eaa70632abf Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH v2 2/3] media: uapi: Add VP9 stateless decoder controls
On Fri, 01 May 2020 13:57:49 -0300
Ezequiel Garcia wrote:
> > > +
> > > +.. tabularcolumns:: |p{1.5cm}|p{6.3cm}|p{9.4cm}|
> > > +
> > > +.. flat-table:: enum v4l2_vp9_reset_frame_context
> > > +:header-rows: 0
> > > +:stub-columns: 0
> > > +:widths: 1 2
> > > +
> > > +* - ``V4L2_VP9_RESET_FRAME_CTX_NONE``
> > > + - Do not reset any frame context.
> > > +* - ``V4L2_VP9_RESET_FRAME_CTX_NONE_ALT``
> > > + - Do not reset any frame context. This is an alternative value for
> > > +V4L2_VP9_RESET_FRAME_CTX_NONE.
> >
> > Add `` around V4L2_VP9_RESET_FRAME_CTX_NONE.
> >
>
> Hm, now that I look closer, what's the point
> of having the NONE_ALT in our uAPI if it
> has same meaning as NONE?
>
> I think it can be removed.
The intent was to match the spec so that one can pass the value
extracted from the bitstream directly.
> >
> > I got several smatch warnings:
> >
> > smatch: ERRORS
> > drivers/media/v4l2-core/v4l2-ctrls.c:1880
> > validate_vp9_frame_decode_params() warn: was && intended here instead of ||?
> >
> > (Commented on this ^^^ one above)
> >
> > drivers/staging/media/rkvdec/rkvdec-vp9.c:426 init_intra_only_probs()
> > error: buffer overflow 'ptr' 9 <= 69
> > drivers/staging/media/rkvdec/rkvdec-vp9.c:1478 rkvdec_vp9_done() error:
> > potentially dereferencing uninitialized 'ctrl'.
> > drivers/staging/media/rkvdec/rkvdec-vp9.c:1483 rkvdec_vp9_done() error:
> > uninitialized symbol 'dec_dst_buf'.
> > drivers/staging/media/rkvdec/rkvdec-vp9.c:941:6: warning: variable 'ret'
> > set but not used [-Wunused-but-set-variable]
> > drivers/staging/media/rkvdec/rkvdec-vp9.c:1466:40: warning: variable 'fctx'
> > set but not used [-Wunused-but-set-variable]
> >
>
> Oh, I'll run smatch and fix them all.
Oops!
[PATCH 0/5] platform/x86: intel-vbtn: Fixes + rework to make it work on more devices
Hi All,
Here is a series of fixes, mostly aimed at fixing commit: de9647efeaa9
("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's")
causing the driver to not bind on some devices where it could and
should report SW_TABLET_MODE.
The last commit makes the driver also work on some devices where it
previously would not work because they lack a VBDL method.
Mario, can you test this on a Dell XPS 9360 (for which you wrote the
de9647efeaa9 commit) to ensure that this series does not cause a
regression there? Also I have a question for you about using the DMI
chassis-type for this / a proposal for dealing with this differently
below the '---' of the commit msg of the 4th patch.
Regards,
Hans
