Hello,
This series fixes the crash seen on the Qualcomm SM8450 chipset with the
LLCC/EDAC drivers. The problem was due to the Qcom EDAC driver using the
fixed LLCC register offsets for detecting the LLCC errors.
This seems to have worked for SoCs till SM8450. But in SM8450, the LLCC
register offsets were changed. So accessing the fixed offsets causes the
crash on this platform.
So for fixing this issue, and also to make it work on future SoCs, let's
pass the LLCC offsets from the Qcom LLCC driver based on the individual
SoCs and let the EDAC driver make use of them.
This series has been tested on SM8450 based dev board.
Thanks,
Mani
Manivannan Sadhasivam (2):
soc: qcom: llcc: Pass SoC specific EDAC register offsets to EDAC
driver
EDAC/qcom: Get rid of hardcoded register offsets
drivers/edac/qcom_edac.c | 112 ++++++++++++++---------------
drivers/soc/qcom/llcc-qcom.c | 64 +++++++++++++++++
include/linux/soc/qcom/llcc-qcom.h | 35 +++++++--
3 files changed, 147 insertions(+), 64 deletions(-)
--
2.25.1
The LLCC EDAC register offsets varies between each SoC. Hardcoding the
register offsets won't work and will often result in crash due to
accessing the wrong locations.
Hence, get the register offsets from the LLCC driver matching the
individual SoCs.
Signed-off-by: Manivannan Sadhasivam <[email protected]>
---
drivers/edac/qcom_edac.c | 112 ++++++++++++++---------------
include/linux/soc/qcom/llcc-qcom.h | 35 +++++++--
2 files changed, 83 insertions(+), 64 deletions(-)
diff --git a/drivers/edac/qcom_edac.c b/drivers/edac/qcom_edac.c
index 97a27e42dd61..500360cc5258 100644
--- a/drivers/edac/qcom_edac.c
+++ b/drivers/edac/qcom_edac.c
@@ -21,30 +21,9 @@
#define TRP_SYN_REG_CNT 6
#define DRP_SYN_REG_CNT 8
-#define LLCC_COMMON_STATUS0 0x0003000c
#define LLCC_LB_CNT_MASK GENMASK(31, 28)
#define LLCC_LB_CNT_SHIFT 28
-/* Single & double bit syndrome register offsets */
-#define TRP_ECC_SB_ERR_SYN0 0x0002304c
-#define TRP_ECC_DB_ERR_SYN0 0x00020370
-#define DRP_ECC_SB_ERR_SYN0 0x0004204c
-#define DRP_ECC_DB_ERR_SYN0 0x00042070
-
-/* Error register offsets */
-#define TRP_ECC_ERROR_STATUS1 0x00020348
-#define TRP_ECC_ERROR_STATUS0 0x00020344
-#define DRP_ECC_ERROR_STATUS1 0x00042048
-#define DRP_ECC_ERROR_STATUS0 0x00042044
-
-/* TRP, DRP interrupt register offsets */
-#define DRP_INTERRUPT_STATUS 0x00041000
-#define TRP_INTERRUPT_0_STATUS 0x00020480
-#define DRP_INTERRUPT_CLEAR 0x00041008
-#define DRP_ECC_ERROR_CNTR_CLEAR 0x00040004
-#define TRP_INTERRUPT_0_CLEAR 0x00020484
-#define TRP_ECC_ERROR_CNTR_CLEAR 0x00020440
-
/* Mask and shift macros */
#define ECC_DB_ERR_COUNT_MASK GENMASK(4, 0)
#define ECC_DB_ERR_WAYS_MASK GENMASK(31, 16)
@@ -60,15 +39,6 @@
#define DRP_TRP_INT_CLEAR GENMASK(1, 0)
#define DRP_TRP_CNT_CLEAR GENMASK(1, 0)
-/* Config registers offsets*/
-#define DRP_ECC_ERROR_CFG 0x00040000
-
-/* Tag RAM, Data RAM interrupt register offsets */
-#define CMN_INTERRUPT_0_ENABLE 0x0003001c
-#define CMN_INTERRUPT_2_ENABLE 0x0003003c
-#define TRP_INTERRUPT_0_ENABLE 0x00020488
-#define DRP_INTERRUPT_ENABLE 0x0004100c
-
#define SB_ERROR_THRESHOLD 0x1
#define SB_ERROR_THRESHOLD_SHIFT 24
#define SB_DB_TRP_INTERRUPT_ENABLE 0x3
@@ -86,9 +56,6 @@ enum {
static const struct llcc_edac_reg_data edac_reg_data[] = {
[LLCC_DRAM_CE] = {
.name = "DRAM Single-bit",
- .synd_reg = DRP_ECC_SB_ERR_SYN0,
- .count_status_reg = DRP_ECC_ERROR_STATUS1,
- .ways_status_reg = DRP_ECC_ERROR_STATUS0,
.reg_cnt = DRP_SYN_REG_CNT,
.count_mask = ECC_SB_ERR_COUNT_MASK,
.ways_mask = ECC_SB_ERR_WAYS_MASK,
@@ -96,9 +63,6 @@ static const struct llcc_edac_reg_data edac_reg_data[] = {
},
[LLCC_DRAM_UE] = {
.name = "DRAM Double-bit",
- .synd_reg = DRP_ECC_DB_ERR_SYN0,
- .count_status_reg = DRP_ECC_ERROR_STATUS1,
- .ways_status_reg = DRP_ECC_ERROR_STATUS0,
.reg_cnt = DRP_SYN_REG_CNT,
.count_mask = ECC_DB_ERR_COUNT_MASK,
.ways_mask = ECC_DB_ERR_WAYS_MASK,
@@ -106,9 +70,6 @@ static const struct llcc_edac_reg_data edac_reg_data[] = {
},
[LLCC_TRAM_CE] = {
.name = "TRAM Single-bit",
- .synd_reg = TRP_ECC_SB_ERR_SYN0,
- .count_status_reg = TRP_ECC_ERROR_STATUS1,
- .ways_status_reg = TRP_ECC_ERROR_STATUS0,
.reg_cnt = TRP_SYN_REG_CNT,
.count_mask = ECC_SB_ERR_COUNT_MASK,
.ways_mask = ECC_SB_ERR_WAYS_MASK,
@@ -116,9 +77,6 @@ static const struct llcc_edac_reg_data edac_reg_data[] = {
},
[LLCC_TRAM_UE] = {
.name = "TRAM Double-bit",
- .synd_reg = TRP_ECC_DB_ERR_SYN0,
- .count_status_reg = TRP_ECC_ERROR_STATUS1,
- .ways_status_reg = TRP_ECC_ERROR_STATUS0,
.reg_cnt = TRP_SYN_REG_CNT,
.count_mask = ECC_DB_ERR_COUNT_MASK,
.ways_mask = ECC_DB_ERR_WAYS_MASK,
@@ -126,7 +84,7 @@ static const struct llcc_edac_reg_data edac_reg_data[] = {
},
};
-static int qcom_llcc_core_setup(struct regmap *llcc_bcast_regmap)
+static int qcom_llcc_core_setup(struct llcc_drv_data *drv, struct regmap *llcc_bcast_regmap)
{
u32 sb_err_threshold;
int ret;
@@ -135,31 +93,31 @@ static int qcom_llcc_core_setup(struct regmap *llcc_bcast_regmap)
* Configure interrupt enable registers such that Tag, Data RAM related
* interrupts are propagated to interrupt controller for servicing
*/
- ret = regmap_update_bits(llcc_bcast_regmap, CMN_INTERRUPT_2_ENABLE,
+ ret = regmap_update_bits(llcc_bcast_regmap, drv->edac_reg->cmn_interrupt_2_enable,
TRP0_INTERRUPT_ENABLE,
TRP0_INTERRUPT_ENABLE);
if (ret)
return ret;
- ret = regmap_update_bits(llcc_bcast_regmap, TRP_INTERRUPT_0_ENABLE,
+ ret = regmap_update_bits(llcc_bcast_regmap, drv->edac_reg->trp_interrupt_0_enable,
SB_DB_TRP_INTERRUPT_ENABLE,
SB_DB_TRP_INTERRUPT_ENABLE);
if (ret)
return ret;
sb_err_threshold = (SB_ERROR_THRESHOLD << SB_ERROR_THRESHOLD_SHIFT);
- ret = regmap_write(llcc_bcast_regmap, DRP_ECC_ERROR_CFG,
+ ret = regmap_write(llcc_bcast_regmap, drv->edac_reg->drp_ecc_error_cfg,
sb_err_threshold);
if (ret)
return ret;
- ret = regmap_update_bits(llcc_bcast_regmap, CMN_INTERRUPT_2_ENABLE,
+ ret = regmap_update_bits(llcc_bcast_regmap, drv->edac_reg->cmn_interrupt_2_enable,
DRP0_INTERRUPT_ENABLE,
DRP0_INTERRUPT_ENABLE);
if (ret)
return ret;
- ret = regmap_write(llcc_bcast_regmap, DRP_INTERRUPT_ENABLE,
+ ret = regmap_write(llcc_bcast_regmap, drv->edac_reg->drp_interrupt_enable,
SB_DB_DRP_INTERRUPT_ENABLE);
return ret;
}
@@ -173,24 +131,24 @@ qcom_llcc_clear_error_status(int err_type, struct llcc_drv_data *drv)
switch (err_type) {
case LLCC_DRAM_CE:
case LLCC_DRAM_UE:
- ret = regmap_write(drv->bcast_regmap, DRP_INTERRUPT_CLEAR,
+ ret = regmap_write(drv->bcast_regmap, drv->edac_reg->drp_interrupt_clear,
DRP_TRP_INT_CLEAR);
if (ret)
return ret;
- ret = regmap_write(drv->bcast_regmap, DRP_ECC_ERROR_CNTR_CLEAR,
+ ret = regmap_write(drv->bcast_regmap, drv->edac_reg->drp_ecc_error_cntr_clear,
DRP_TRP_CNT_CLEAR);
if (ret)
return ret;
break;
case LLCC_TRAM_CE:
case LLCC_TRAM_UE:
- ret = regmap_write(drv->bcast_regmap, TRP_INTERRUPT_0_CLEAR,
+ ret = regmap_write(drv->bcast_regmap, drv->edac_reg->trp_interrupt_0_clear,
DRP_TRP_INT_CLEAR);
if (ret)
return ret;
- ret = regmap_write(drv->bcast_regmap, TRP_ECC_ERROR_CNTR_CLEAR,
+ ret = regmap_write(drv->bcast_regmap, drv->edac_reg->trp_ecc_error_cntr_clear,
DRP_TRP_CNT_CLEAR);
if (ret)
return ret;
@@ -203,16 +161,54 @@ qcom_llcc_clear_error_status(int err_type, struct llcc_drv_data *drv)
return ret;
}
+struct qcom_llcc_syn_regs {
+ u32 synd_reg;
+ u32 count_status_reg;
+ u32 ways_status_reg;
+};
+
+static void get_reg_offsets(struct llcc_drv_data *drv, int err_type,
+ struct qcom_llcc_syn_regs *syn_regs)
+{
+ const struct llcc_edac_reg *edac_reg = drv->edac_reg;
+
+ switch (err_type) {
+ case LLCC_DRAM_CE:
+ syn_regs->synd_reg = edac_reg->drp_ecc_sb_err_syn0;
+ syn_regs->count_status_reg = edac_reg->drp_ecc_error_status1;
+ syn_regs->ways_status_reg = edac_reg->drp_ecc_error_status0;
+ break;
+ case LLCC_DRAM_UE:
+ syn_regs->synd_reg = edac_reg->drp_ecc_db_err_syn0;
+ syn_regs->count_status_reg = edac_reg->drp_ecc_error_status1;
+ syn_regs->ways_status_reg = edac_reg->drp_ecc_error_status0;
+ break;
+ case LLCC_TRAM_CE:
+ syn_regs->synd_reg = edac_reg->trp_ecc_sb_err_syn0;
+ syn_regs->count_status_reg = edac_reg->trp_ecc_error_status1;
+ syn_regs->ways_status_reg = edac_reg->trp_ecc_error_status0;
+ break;
+ case LLCC_TRAM_UE:
+ syn_regs->synd_reg = edac_reg->trp_ecc_db_err_syn0;
+ syn_regs->count_status_reg = edac_reg->trp_ecc_error_status1;
+ syn_regs->ways_status_reg = edac_reg->trp_ecc_error_status0;
+ break;
+ }
+}
+
/* Dump Syndrome registers data for Tag RAM, Data RAM bit errors*/
static int
dump_syn_reg_values(struct llcc_drv_data *drv, u32 bank, int err_type)
{
struct llcc_edac_reg_data reg_data = edac_reg_data[err_type];
+ struct qcom_llcc_syn_regs regs = { };
int err_cnt, err_ways, ret, i;
u32 synd_reg, synd_val;
+ get_reg_offsets(drv, err_type, ®s);
+
for (i = 0; i < reg_data.reg_cnt; i++) {
- synd_reg = reg_data.synd_reg + (i * 4);
+ synd_reg = regs.synd_reg + (i * 4);
ret = regmap_read(drv->regmap, drv->offsets[bank] + synd_reg,
&synd_val);
if (ret)
@@ -223,7 +219,7 @@ dump_syn_reg_values(struct llcc_drv_data *drv, u32 bank, int err_type)
}
ret = regmap_read(drv->regmap,
- drv->offsets[bank] + reg_data.count_status_reg,
+ drv->offsets[bank] + regs.count_status_reg,
&err_cnt);
if (ret)
goto clear;
@@ -234,7 +230,7 @@ dump_syn_reg_values(struct llcc_drv_data *drv, u32 bank, int err_type)
reg_data.name, err_cnt);
ret = regmap_read(drv->regmap,
- drv->offsets[bank] + reg_data.ways_status_reg,
+ drv->offsets[bank] + regs.ways_status_reg,
&err_ways);
if (ret)
goto clear;
@@ -297,7 +293,7 @@ llcc_ecc_irq_handler(int irq, void *edev_ctl)
/* Iterate over the banks and look for Tag RAM or Data RAM errors */
for (i = 0; i < drv->num_banks; i++) {
ret = regmap_read(drv->regmap,
- drv->offsets[i] + DRP_INTERRUPT_STATUS,
+ drv->offsets[i] + drv->edac_reg->drp_interrupt_status,
&drp_error);
if (!ret && (drp_error & SB_ECC_ERROR)) {
@@ -313,7 +309,7 @@ llcc_ecc_irq_handler(int irq, void *edev_ctl)
irq_rc = IRQ_HANDLED;
ret = regmap_read(drv->regmap,
- drv->offsets[i] + TRP_INTERRUPT_0_STATUS,
+ drv->offsets[i] + drv->edac_reg->trp_interrupt_0_status,
&trp_error);
if (!ret && (trp_error & SB_ECC_ERROR)) {
@@ -340,7 +336,7 @@ static int qcom_llcc_edac_probe(struct platform_device *pdev)
int ecc_irq;
int rc;
- rc = qcom_llcc_core_setup(llcc_driv_data->bcast_regmap);
+ rc = qcom_llcc_core_setup(llcc_driv_data, llcc_driv_data->bcast_regmap);
if (rc)
return rc;
diff --git a/include/linux/soc/qcom/llcc-qcom.h b/include/linux/soc/qcom/llcc-qcom.h
index 0bc21ee58fac..a36ed7ffcb28 100644
--- a/include/linux/soc/qcom/llcc-qcom.h
+++ b/include/linux/soc/qcom/llcc-qcom.h
@@ -55,9 +55,6 @@ struct llcc_slice_desc {
/**
* struct llcc_edac_reg_data - llcc edac registers data for each error type
* @name: Name of the error
- * @synd_reg: Syndrome register address
- * @count_status_reg: Status register address to read the error count
- * @ways_status_reg: Status register address to read the error ways
* @reg_cnt: Number of registers
* @count_mask: Mask value to get the error count
* @ways_mask: Mask value to get the error ways
@@ -66,9 +63,6 @@ struct llcc_slice_desc {
*/
struct llcc_edac_reg_data {
char *name;
- u64 synd_reg;
- u64 count_status_reg;
- u64 ways_status_reg;
u32 reg_cnt;
u32 count_mask;
u32 ways_mask;
@@ -76,6 +70,34 @@ struct llcc_edac_reg_data {
u8 ways_shift;
};
+struct llcc_edac_reg {
+ /* LLCC TRP registers */
+ u32 trp_ecc_error_status0;
+ u32 trp_ecc_error_status1;
+ u32 trp_ecc_sb_err_syn0;
+ u32 trp_ecc_db_err_syn0;
+ u32 trp_ecc_error_cntr_clear;
+ u32 trp_interrupt_0_status;
+ u32 trp_interrupt_0_clear;
+ u32 trp_interrupt_0_enable;
+
+ /* LLCC Common registers */
+ u32 cmn_status0;
+ u32 cmn_interrupt_0_enable;
+ u32 cmn_interrupt_2_enable;
+
+ /* LLCC DRP registers */
+ u32 drp_ecc_error_cfg;
+ u32 drp_ecc_error_cntr_clear;
+ u32 drp_interrupt_status;
+ u32 drp_interrupt_clear;
+ u32 drp_interrupt_enable;
+ u32 drp_ecc_error_status0;
+ u32 drp_ecc_error_status1;
+ u32 drp_ecc_sb_err_syn0;
+ u32 drp_ecc_db_err_syn0;
+};
+
/**
* struct llcc_drv_data - Data associated with the llcc driver
* @regmap: regmap associated with the llcc device
@@ -94,6 +116,7 @@ struct llcc_drv_data {
struct regmap *regmap;
struct regmap *bcast_regmap;
const struct llcc_slice_config *cfg;
+ const struct llcc_edac_reg *edac_reg;
struct mutex lock;
u32 cfg_size;
u32 max_slices;
--
2.25.1
On Thu, Aug 11, 2022 at 12:48:37PM +0200, Borislav Petkov wrote:
> On Thu, Aug 11, 2022 at 03:39:22PM +0530, Manivannan Sadhasivam wrote:
> > Hello,
> >
> > This series fixes the crash seen on the Qualcomm SM8450 chipset with the
> > LLCC/EDAC drivers. The problem was due to the Qcom EDAC driver using the
> > fixed LLCC register offsets for detecting the LLCC errors.
>
> I see you've CCed the QCOM maintainers using different email addresses:
>
> $ ./scripts/get_maintainer.pl -f drivers/edac/qcom_edac.c
> Channagoud Kadabi <[email protected]> (maintainer:EDAC-QCOM)
> Venkata Narendra Kumar Gutta <[email protected]> (maintainer:EDAC-QCOM)
>
> Does MAINTAINERS need updating?
No, it doesn't. The email addresses you used, bounce:
Delivery has failed to these recipients or groups:
[email protected]<mailto:[email protected]>
The email address you entered couldn't be found. Please check the recipient's email address and try to resend the message. If the problem continues,
+please contact your email admin.
[email protected]<mailto:[email protected]>
The email address you entered couldn't be found. Please check the recipient's email address and try to resend the message. If the problem continues,
+please contact your email admin.
In the future, when you wonder who to Cc and how,
scripts/get_maintainer.pl
is your friend.
HTH.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Thu, Aug 11, 2022 at 03:39:22PM +0530, Manivannan Sadhasivam wrote:
> Hello,
>
> This series fixes the crash seen on the Qualcomm SM8450 chipset with the
> LLCC/EDAC drivers. The problem was due to the Qcom EDAC driver using the
> fixed LLCC register offsets for detecting the LLCC errors.
I see you've CCed the QCOM maintainers using different email addresses:
$ ./scripts/get_maintainer.pl -f drivers/edac/qcom_edac.c
Channagoud Kadabi <[email protected]> (maintainer:EDAC-QCOM)
Venkata Narendra Kumar Gutta <[email protected]> (maintainer:EDAC-QCOM)
Does MAINTAINERS need updating?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Thu, Aug 11, 2022 at 12:53:30PM +0200, Borislav Petkov wrote:
> On Thu, Aug 11, 2022 at 12:48:37PM +0200, Borislav Petkov wrote:
> > On Thu, Aug 11, 2022 at 03:39:22PM +0530, Manivannan Sadhasivam wrote:
> > > Hello,
> > >
> > > This series fixes the crash seen on the Qualcomm SM8450 chipset with the
> > > LLCC/EDAC drivers. The problem was due to the Qcom EDAC driver using the
> > > fixed LLCC register offsets for detecting the LLCC errors.
> >
> > I see you've CCed the QCOM maintainers using different email addresses:
> >
> > $ ./scripts/get_maintainer.pl -f drivers/edac/qcom_edac.c
> > Channagoud Kadabi <[email protected]> (maintainer:EDAC-QCOM)
> > Venkata Narendra Kumar Gutta <[email protected]> (maintainer:EDAC-QCOM)
> >
> > Does MAINTAINERS need updating?
>
> No, it doesn't. The email addresses you used, bounce:
>
> Delivery has failed to these recipients or groups:
>
> [email protected]<mailto:[email protected]>
> The email address you entered couldn't be found. Please check the recipient's email address and try to resend the message. If the problem continues,
> +please contact your email admin.
>
>
> [email protected]<mailto:[email protected]>
> The email address you entered couldn't be found. Please check the recipient's email address and try to resend the message. If the problem continues,
> +please contact your email admin.
>
> In the future, when you wonder who to Cc and how,
>
> scripts/get_maintainer.pl
>
> is your friend.
>
I know get_maintainer.pl :) But the problem is, Qualcomm recently
switched their email domain from codeaurora.org to quicinc.com. So even
if I use the maintainers codeaurora domain now, they will bounce.
For that reason, I used their quicinc domain addresses. But since they
are bouncing, it looks like the maintainers left Qualcomm :/
Thanks,
Mani
> HTH.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
On Thu, Aug 11, 2022 at 04:50:32PM +0530, Manivannan Sadhasivam wrote:
> I know get_maintainer.pl :) But the problem is, Qualcomm recently
> switched their email domain from codeaurora.org to quicinc.com.
Great:
$ git grep codeaurora.org MAINTAINERS | wc -l
5
;-\
> So even if I use the maintainers codeaurora domain now, they will
> bounce.
Hmm, so the mails I sent with codeaurora on Cc didn't bounce back - I
got only the quicinc bounces. That doesn't mean that codeaurora actually
gets delivered...
> For that reason, I used their quicinc domain addresses. But since they
> are bouncing, it looks like the maintainers left Qualcomm :/
Hmm, is there some way to get in touch with those folks?
Or whoever is taking over those drivers?
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Thu, Aug 11, 2022 at 01:33:06PM +0200, Borislav Petkov wrote:
> On Thu, Aug 11, 2022 at 04:50:32PM +0530, Manivannan Sadhasivam wrote:
> > I know get_maintainer.pl :) But the problem is, Qualcomm recently
> > switched their email domain from codeaurora.org to quicinc.com.
>
> Great:
>
> $ git grep codeaurora.org MAINTAINERS | wc -l
> 5
>
Yep! Most of the active developers have already changed their domains in
MAINTAINERS file. But the left ones are either not actively maintained
(yeah bad) or the maintainers have left Qualcomm.
> ;-\
>
> > So even if I use the maintainers codeaurora domain now, they will
> > bounce.
>
> Hmm, so the mails I sent with codeaurora on Cc didn't bounce back - I
> got only the quicinc bounces. That doesn't mean that codeaurora actually
> gets delivered...
>
Not sure why. It was supposed to bounce. But could be that Qualcomm IT
decided to not bounce anymore since they have got enough complaints from
developers ;)
> > For that reason, I used their quicinc domain addresses. But since they
> > are bouncing, it looks like the maintainers left Qualcomm :/
>
> Hmm, is there some way to get in touch with those folks?
>
I don't think so. I checked in the internal Qualcomm database and
confirmed that I couldn't find the maintainers names there.
> Or whoever is taking over those drivers?
>
LLCC is maintained by Bjorn (CCed) since it falls under soc/qcom. But I'm
not sure about EDAC. I think we should mark it as not maintainted until we
find a volunteer.
Bjorn, thoughts?
Thanks,
Mani
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
Clipped the bouncing email addresses...
On Thu, Aug 11, 2022 at 05:23:34PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Aug 11, 2022 at 01:33:06PM +0200, Borislav Petkov wrote:
> > On Thu, Aug 11, 2022 at 04:50:32PM +0530, Manivannan Sadhasivam wrote:
> > > I know get_maintainer.pl :) But the problem is, Qualcomm recently
> > > switched their email domain from codeaurora.org to quicinc.com.
> >
> > Great:
> >
> > $ git grep codeaurora.org MAINTAINERS | wc -l
> > 5
> >
>
> Yep! Most of the active developers have already changed their domains in
> MAINTAINERS file. But the left ones are either not actively maintained
> (yeah bad) or the maintainers have left Qualcomm.
>
> > ;-\
> >
> > > So even if I use the maintainers codeaurora domain now, they will
> > > bounce.
> >
> > Hmm, so the mails I sent with codeaurora on Cc didn't bounce back - I
> > got only the quicinc bounces. That doesn't mean that codeaurora actually
> > gets delivered...
> >
>
> Not sure why. It was supposed to bounce. But could be that Qualcomm IT
> decided to not bounce anymore since they have got enough complaints from
> developers ;)
>
Okay, seems to be bouncing for me:
The response from the remote server was:
585 5.1.1 <[email protected]>: Recipient address rejected: undeliverable address: No such user here.
585 5.1.1 <[email protected]>: Recipient address rejected: undeliverable address: No such user here.
Thanks,
Mani
> > > For that reason, I used their quicinc domain addresses. But since they
> > > are bouncing, it looks like the maintainers left Qualcomm :/
> >
> > Hmm, is there some way to get in touch with those folks?
> >
>
> I don't think so. I checked in the internal Qualcomm database and
> confirmed that I couldn't find the maintainers names there.
>
> > Or whoever is taking over those drivers?
> >
>
> LLCC is maintained by Bjorn (CCed) since it falls under soc/qcom. But I'm
> not sure about EDAC. I think we should mark it as not maintainted until we
> find a volunteer.
>
> Bjorn, thoughts?
>
> Thanks,
> Mani
>
> > Thx.
> >
> > --
> > Regards/Gruss,
> > Boris.
> >
> > https://people.kernel.org/tglx/notes-about-netiquette
Hello Mani,
On 8/11/2022 4:57 AM, Manivannan Sadhasivam wrote:
> Clipped the bouncing email addresses...
>
> On Thu, Aug 11, 2022 at 05:23:34PM +0530, Manivannan Sadhasivam wrote:
>> On Thu, Aug 11, 2022 at 01:33:06PM +0200, Borislav Petkov wrote:
>>> On Thu, Aug 11, 2022 at 04:50:32PM +0530, Manivannan Sadhasivam wrote:
>>>> I know get_maintainer.pl :) But the problem is, Qualcomm recently
>>>> switched their email domain from codeaurora.org to quicinc.com.
>>>
>>> Great:
>>>
>>> $ git grep codeaurora.org MAINTAINERS | wc -l
>>> 5
>>>
>>
>> Yep! Most of the active developers have already changed their domains in
>> MAINTAINERS file. But the left ones are either not actively maintained
>> (yeah bad) or the maintainers have left Qualcomm.
>>
>>> ;-\
>>>
>>>> So even if I use the maintainers codeaurora domain now, they will
>>>> bounce.
>>>
>>> Hmm, so the mails I sent with codeaurora on Cc didn't bounce back - I
>>> got only the quicinc bounces. That doesn't mean that codeaurora actually
>>> gets delivered...
>>>
>>
>> Not sure why. It was supposed to bounce. But could be that Qualcomm IT
>> decided to not bounce anymore since they have got enough complaints from
>> developers ;)
>>
>
> Okay, seems to be bouncing for me:
>
> The response from the remote server was:
> 585 5.1.1 <[email protected]>: Recipient address rejected: undeliverable address: No such user here.
> 585 5.1.1 <[email protected]>: Recipient address rejected: undeliverable address: No such user here.
It is ok if someone from Linaro team becomes the maintainer for this
driver.
---Trilok Soni
On Thu, Aug 11, 2022 at 09:08:14AM -0700, Trilok Soni wrote:
> Hello Mani,
>
> On 8/11/2022 4:57 AM, Manivannan Sadhasivam wrote:
> > Clipped the bouncing email addresses...
> >
> > On Thu, Aug 11, 2022 at 05:23:34PM +0530, Manivannan Sadhasivam wrote:
> > > On Thu, Aug 11, 2022 at 01:33:06PM +0200, Borislav Petkov wrote:
> > > > On Thu, Aug 11, 2022 at 04:50:32PM +0530, Manivannan Sadhasivam wrote:
> > > > > I know get_maintainer.pl :) But the problem is, Qualcomm recently
> > > > > switched their email domain from codeaurora.org to quicinc.com.
> > > >
> > > > Great:
> > > >
> > > > $ git grep codeaurora.org MAINTAINERS | wc -l
> > > > 5
> > > >
> > >
> > > Yep! Most of the active developers have already changed their domains in
> > > MAINTAINERS file. But the left ones are either not actively maintained
> > > (yeah bad) or the maintainers have left Qualcomm.
> > >
> > > > ;-\
> > > >
> > > > > So even if I use the maintainers codeaurora domain now, they will
> > > > > bounce.
> > > >
> > > > Hmm, so the mails I sent with codeaurora on Cc didn't bounce back - I
> > > > got only the quicinc bounces. That doesn't mean that codeaurora actually
> > > > gets delivered...
> > > >
> > >
> > > Not sure why. It was supposed to bounce. But could be that Qualcomm IT
> > > decided to not bounce anymore since they have got enough complaints from
> > > developers ;)
> > >
> >
> > Okay, seems to be bouncing for me:
> >
> > The response from the remote server was:
> > 585 5.1.1 <[email protected]>: Recipient address rejected: undeliverable address: No such user here.
> > 585 5.1.1 <[email protected]>: Recipient address rejected: undeliverable address: No such user here.
>
> It is ok if someone from Linaro team becomes the maintainer for this driver.
>
Thanks Trilok for the confirmation! I'll add myself as the maintainer.
Thanks,
Mani
> ---Trilok Soni
--
மணிவண்ணன் சதாசிவம்