Re: [PATCH v1 1/1] ACPI: NFIT: Import GUID before use

2021-04-15 Thread Dan Williams
On Thu, Apr 15, 2021 at 6:59 AM Andy Shevchenko
 wrote:
>
> Strictly speaking the comparison between guid_t and raw buffer
> is not correct. Import GUID to variable of guid_t type and then
> compare.

Hmm, what about something like the following instead, because it adds
safety. Any concerns about evaluating x twice in a macro should be
alleviated by the fact that ARRAY_SIZE() will fail the build if (x) is
not an array.

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 8c5dde628405..bac01eec07a6 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -681,7 +681,7 @@ int nfit_spa_type(struct acpi_nfit_system_address *spa)
int i;

for (i = 0; i < NFIT_UUID_MAX; i++)
-   if (guid_equal(to_nfit_uuid(i), (guid_t *)>range_guid))
+   if (guid_equal(to_nfit_uuid(i), cast_guid(spa->range_guid)))
return i;
return -1;
 }
diff --git a/include/linux/uuid.h b/include/linux/uuid.h
index 8cdc0d3567cd..cec1dc2ab994 100644
--- a/include/linux/uuid.h
+++ b/include/linux/uuid.h
@@ -33,6 +33,9 @@ typedef struct {
 extern const guid_t guid_null;
 extern const uuid_t uuid_null;

+#define cast_guid(x) ({ BUILD_BUG_ON(ARRAY_SIZE(x) != 16); (guid_t *)&(x); })
+#define cast_uuid(x) ({ BUILD_BUG_ON(ARRAY_SIZE(x) != 16); (uuid_t *)&(x); })
+
 static inline bool guid_equal(const guid_t *u1, const guid_t *u2)
 {
return memcmp(u1, u2, sizeof(guid_t)) == 0;
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org


Re: [PATCH] powerpc/papr_scm: Reduce error severity if nvdimm stats inaccessible

2021-04-15 Thread Dan Williams
On Thu, Apr 15, 2021 at 4:44 AM Vaibhav Jain  wrote:
>
> Thanks for looking into this Dan,
>
> Dan Williams  writes:
>
> > On Wed, Apr 14, 2021 at 5:40 AM Vaibhav Jain  wrote:
> >>
> >> Currently drc_pmem_qeury_stats() generates a dev_err in case
> >> "Enable Performance Information Collection" feature is disabled from
> >> HMC. The error is of the form below:
> >>
> >> papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Failed to query
> >>  performance stats, Err:-10
> >>
> >> This error message confuses users as it implies a possible problem
> >> with the nvdimm even though its due to a disabled feature.
> >>
> >> So we fix this by explicitly handling the H_AUTHORITY error from the
> >> H_SCM_PERFORMANCE_STATS hcall and generating a warning instead of an
> >> error, saying that "Performance stats in-accessible".
> >>
> >> Fixes: 2d02bf835e57('powerpc/papr_scm: Fetch nvdimm performance stats from 
> >> PHYP')
> >> Signed-off-by: Vaibhav Jain 
> >> ---
> >>  arch/powerpc/platforms/pseries/papr_scm.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c 
> >> b/arch/powerpc/platforms/pseries/papr_scm.c
> >> index 835163f54244..9216424f8be3 100644
> >> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> >> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> >> @@ -277,6 +277,9 @@ static ssize_t drc_pmem_query_stats(struct 
> >> papr_scm_priv *p,
> >> dev_err(>pdev->dev,
> >> "Unknown performance stats, Err:0x%016lX\n", 
> >> ret[0]);
> >> return -ENOENT;
> >> +   } else if (rc == H_AUTHORITY) {
> >> +   dev_warn(>pdev->dev, "Performance stats in-accessible");
> >> +   return -EPERM;
> >
> > So userspace can spam the kernel log? Why is kernel log message needed
> > at all? EPERM told the caller what happened.
> Currently this error message is only reported during probe of the
> nvdimm. So userspace cannot directly spam kernel log.

Oh, ok, I saw things like papr_pdsm_fuel_gauge() in the call stack and
thought this was reachable through an ioctl. Sorry for the noise.
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org


[PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer

2021-04-15 Thread Andy Shevchenko
Strictly speaking the comparison between guid_t and raw buffer
is not correct. Return to plain memcmp() since the data structures
haven't changed to use uuid_t / guid_t the current state of affairs
is inconsistent. Either it should be changed altogether or left
as is.

Signed-off-by: Andy Shevchenko 
---
 drivers/nvdimm/btt_devs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
index 05feb97e11ce..82bcd2e86a18 100644
--- a/drivers/nvdimm/btt_devs.c
+++ b/drivers/nvdimm/btt_devs.c
@@ -244,13 +244,14 @@ struct device *nd_btt_create(struct nd_region *nd_region)
  */
 bool nd_btt_arena_is_valid(struct nd_btt *nd_btt, struct btt_sb *super)
 {
+   static const u8 null_uuid[16];
const u8 *parent_uuid = nd_dev_to_uuid(_btt->ndns->dev);
u64 checksum;
 
if (memcmp(super->signature, BTT_SIG, BTT_SIG_LEN) != 0)
return false;
 
-   if (!guid_is_null((guid_t *)>parent_uuid))
+   if (memcmp(super->parent_uuid, null_uuid, 16) != 0)
if (memcmp(super->parent_uuid, parent_uuid, 16) != 0)
return false;
 
-- 
2.30.2
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org


[PATCH v1 1/1] ACPI: NFIT: Import GUID before use

2021-04-15 Thread Andy Shevchenko
Strictly speaking the comparison between guid_t and raw buffer
is not correct. Import GUID to variable of guid_t type and then
compare.

Signed-off-by: Andy Shevchenko 
---
 drivers/acpi/nfit/core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 958aaac869e8..6d8a1a93636a 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -678,10 +678,12 @@ static const char *spa_type_name(u16 type)
 
 int nfit_spa_type(struct acpi_nfit_system_address *spa)
 {
+   guid_t guid;
int i;
 
+   import_guid(, spa->range_guid);
for (i = 0; i < NFIT_UUID_MAX; i++)
-   if (guid_equal(to_nfit_uuid(i), (guid_t *)>range_guid))
+   if (guid_equal(to_nfit_uuid(i), ))
return i;
return -1;
 }
-- 
2.30.2
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org


Purchase-Order 73921

2021-04-15 Thread Kozin
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org


Re: [PATCH] powerpc/papr_scm: Reduce error severity if nvdimm stats inaccessible

2021-04-15 Thread Vaibhav Jain
Ira Weiny  writes:

> On Wed, Apr 14, 2021 at 09:51:40PM +0530, Vaibhav Jain wrote:
>> Thanks for looking into this patch Ira,
>> 
>> Ira Weiny  writes:
>> 
>> > On Wed, Apr 14, 2021 at 06:10:26PM +0530, Vaibhav Jain wrote:
>> >> Currently drc_pmem_qeury_stats() generates a dev_err in case
>> >> "Enable Performance Information Collection" feature is disabled from
>> >> HMC. The error is of the form below:
>> >> 
>> >> papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Failed to query
>> >>performance stats, Err:-10
>> >> 
>> >> This error message confuses users as it implies a possible problem
>> >> with the nvdimm even though its due to a disabled feature.
>> >> 
>> >> So we fix this by explicitly handling the H_AUTHORITY error from the
>> >> H_SCM_PERFORMANCE_STATS hcall and generating a warning instead of an
>> >> error, saying that "Performance stats in-accessible".
>> >> 
>> >> Fixes: 2d02bf835e57('powerpc/papr_scm: Fetch nvdimm performance stats 
>> >> from PHYP')
>> >> Signed-off-by: Vaibhav Jain 
>> >> ---
>> >>  arch/powerpc/platforms/pseries/papr_scm.c | 3 +++
>> >>  1 file changed, 3 insertions(+)
>> >> 
>> >> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c 
>> >> b/arch/powerpc/platforms/pseries/papr_scm.c
>> >> index 835163f54244..9216424f8be3 100644
>> >> --- a/arch/powerpc/platforms/pseries/papr_scm.c
>> >> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
>> >> @@ -277,6 +277,9 @@ static ssize_t drc_pmem_query_stats(struct 
>> >> papr_scm_priv *p,
>> >>   dev_err(>pdev->dev,
>> >>   "Unknown performance stats, Err:0x%016lX\n", ret[0]);
>> >>   return -ENOENT;
>> >> + } else if (rc == H_AUTHORITY) {
>> >> + dev_warn(>pdev->dev, "Performance stats in-accessible");
>> >> + return -EPERM;
>> >
>> > Is this because of a disabled feature or because of permissions?
>> 
>> Its because of a disabled feature that revokes permission for a guest to
>> retrieve performance statistics.
>> 
>> The feature is called "Enable Performance Information Collection" and
>> once disabled the hcall H_SCM_PERFORMANCE_STATS returns an error
>> H_AUTHORITY indicating that the guest doesn't have permission to retrieve
>> performance statistics.
>
> In that case would it be appropriate to have the error message indicate a
> permission issue?
>
> Something like 'permission denied'?

Yes, Something like "Permission denied while accessing performance
stats" might be more clear and intuitive.

Will update the warn message in v2.

>
> Ira
>

-- 
Cheers
~ Vaibhav
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org


Re: [PATCH] powerpc/papr_scm: Reduce error severity if nvdimm stats inaccessible

2021-04-15 Thread Vaibhav Jain
Thanks for looking into this Dan,

Dan Williams  writes:

> On Wed, Apr 14, 2021 at 5:40 AM Vaibhav Jain  wrote:
>>
>> Currently drc_pmem_qeury_stats() generates a dev_err in case
>> "Enable Performance Information Collection" feature is disabled from
>> HMC. The error is of the form below:
>>
>> papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Failed to query
>>  performance stats, Err:-10
>>
>> This error message confuses users as it implies a possible problem
>> with the nvdimm even though its due to a disabled feature.
>>
>> So we fix this by explicitly handling the H_AUTHORITY error from the
>> H_SCM_PERFORMANCE_STATS hcall and generating a warning instead of an
>> error, saying that "Performance stats in-accessible".
>>
>> Fixes: 2d02bf835e57('powerpc/papr_scm: Fetch nvdimm performance stats from 
>> PHYP')
>> Signed-off-by: Vaibhav Jain 
>> ---
>>  arch/powerpc/platforms/pseries/papr_scm.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c 
>> b/arch/powerpc/platforms/pseries/papr_scm.c
>> index 835163f54244..9216424f8be3 100644
>> --- a/arch/powerpc/platforms/pseries/papr_scm.c
>> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
>> @@ -277,6 +277,9 @@ static ssize_t drc_pmem_query_stats(struct papr_scm_priv 
>> *p,
>> dev_err(>pdev->dev,
>> "Unknown performance stats, Err:0x%016lX\n", ret[0]);
>> return -ENOENT;
>> +   } else if (rc == H_AUTHORITY) {
>> +   dev_warn(>pdev->dev, "Performance stats in-accessible");
>> +   return -EPERM;
>
> So userspace can spam the kernel log? Why is kernel log message needed
> at all? EPERM told the caller what happened.
Currently this error message is only reported during probe of the
nvdimm. So userspace cannot directly spam kernel log.

The callsite for this function in papr_scm_nvdimm_init() doesnt handle
specific error codes. Instead in case of an error it only reports that
"Dimm performance stats are unavailable". The log message just
preceeding that mentions the real cause of failure. Thats why just
returning -EPERM wont be usefui.

Alternatively I can update papr_scm_nvdimm_init() to report the error
code returned from drc_pmem_query_stats().

-- 
Cheers
~ Vaibhav
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org


Re: Inquiry Maxim IC

2021-04-15 Thread Yumi







HardFindElectronics Ltd. 


 


Dear Friend, 


Goodday,howareyou?
We are good atHard Findelectronic components:

IC: AD,TI, Maxim,Xilinx, Altera, LT..
MLCC Capacitor: Murata, Samsung, Yageo, AVX, Taiyo..
MLCC Resistor:Yageo,Samsung,Uniohm,Walsin...
Diode Transistor:Vishay, Diodes,NXP,ON,ST..

Here are some of our references:

MAX202EESE+ Maxim 2020+ 0.38usd 
MAX232ESE+T Maxim 2019+ 0.38usd 
MAX3082CSA+T Maxim 2020+ 0.75usd 
MAX3161EEAG+T Maxim 2020+ 5.72usd 
MAX4066ACEE+T Maxim 2019+ 1.905usd 
MAX707CSA+T Maxim 2019+ 0.55usd 
MAX7219CWG+T Maxim 2019+ 0.98usd 
MAX9152EUE+T Maxim 2019+ 1.04usd 
 

We can support you 365days warranty and help you find obsolete parts with good 
price. (1pcs order) 





 Keep smiling every day(* ̄) ̄) 


 


Yumi 


Account 
Manager  


Hard Find Electronics Ltd. 


sourcing hard find electronic components 



315, Shahe Rod, Long Gang District, Shenzhen, CN, 518000
Tel: +86-755-8418 
8103  


Skype/Email: y...@hardfindelectronics.com 


Linkedln: www.linkedin.com/in/yumi-gao 


Facebook: facebook.com/Yumihardfind 


Web: http://www.hardfindelectronics.com/ 


 



If you don't want to receive this mail, pls return with "remove" on the subject 
line. 


 





档铺网——在线文档免费处理 
如果你不想再收到该产品的推荐邮件,请点击这里退订
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org


best jee coaching in bangalore

2021-04-15 Thread giraffelearning123
Best JEE Coaching In Bangalore: Giraffe Learning is India's oldest and first 
institution to introduce JEE Main coaching, way back in 2002. Therefore, we 
have more experience than any other institutions in the field.
Visit : https://www.giraffe-learning.com/jee-coaching-classes.php
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org


best psoriasis treatment in bangalore

2021-04-15 Thread ayurvedavedam123
Dr.Raviraj is one of the best doctor for psoriasis in Bangalore. We have a cure 
for it and we provide the best psoriasis treatment in Bangalore. Visit our 
clinic to know more. 
Visit : https://vedamayurveda.co.in/ayurveda-psoriasis-treatment/
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org