Both irqnum and irqarray properties reflect the same thing:
the number of bits and bytes for interrupts at this
chipset. E. g.:

	irqnum = 8 x irqarray

This can be seen by the way pending interrupts are handled:

	/* During probe time */
	pmic->irqs = devm_kzalloc(dev, pmic->irqnum * sizeof(int), GFP_KERNEL);

	/* While handling IRQs */
	for (i = 0; i < pmic->irqarray; i++) {
		pending = hi6421_spmi_pmic_read(pmic, (i + pmic->irq_addr));
		pending &= 0xff;

		for_each_set_bit(offset, &pending, 8)
			generic_handle_irq(pmic->irqs[offset + i * 8]);

	}

Going further, there are some logic at the driver which assumes
that irqarray is 2:

	/* solve powerkey order */
	if ((i == HISI_IRQ_KEY_NUM) &&
	    ((pending & HISI_IRQ_KEY_VALUE) == HISI_IRQ_KEY_VALUE)) {
		generic_handle_irq(pmic->irqs[HISI_IRQ_KEY_DOWN]);
		generic_handle_irq(pmic->irqs[HISI_IRQ_KEY_UP]);
		pending &= (~HISI_IRQ_KEY_VALUE);
	}

As HISI_IRQ_KEY_DOWN and HISI_IRQ_KEY_UP are fixed values
and don't depend on irqnum/irqarray.

The IRQ addr and mask addr seem to be also fixed, based on some
comments at the OF parsing code. So, get rid of them too,
removing the of parsing function completely.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/e231244e42cb5b56240705cac2f987e11a078038.1597762400.git.mchehab+huawei@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>