Re: [PATCH v4 09/10] gpio: Add a driver for Cadence I3C GPIO expander
On Fri, Mar 30, 2018 at 9:47 AM, Boris Brezillon
wrote:
> Add a driver for Cadence I3C GPIO expander.
>
> Signed-off-by: Boris Brezillon
This is pretty much OK, and I don't want to raise the bar
even higher for you to get this code into the kernel, so:
Acked-by: Linus Walleij
The following is an observation for future improvement:
> +static int cdns_i3c_gpio_read_reg(struct cdns_i3c_gpio *gpioc, u8 reg,
> + u8 *val)
> +{
> + struct i3c_priv_xfer xfers[] = {
> + {
> + .len = sizeof(reg),
> + .data.out = ®,
> + },
> + {
> + .rnw = true,
> + .len = sizeof(*val),
> + .data.in = val,
> + },
> + };
> +
> + return i3c_device_do_priv_xfers(gpioc->i3cdev, xfers,
> + ARRAY_SIZE(xfers));
> +}
> +
> +static int cdns_i3c_gpio_write_reg(struct cdns_i3c_gpio *gpioc, u8 reg,
> + u8 val)
> +{
> + struct i3c_priv_xfer xfers[] = {
> + {
> + .len = sizeof(reg),
> + .data.out = ®,
> + },
> + {
> + .len = sizeof(val),
> + .data.out = &val,
> + },
> + };
> +
> + return i3c_device_do_priv_xfers(gpioc->i3cdev, xfers,
> + ARRAY_SIZE(xfers));
> +}
This is starting to resemble
drivers/base/regmap/regmap-i2c.c
Maybe we should very quickly add regmap-i3c.c as this
infrastructre has had a great positive effect on may kernel
subsystems.
> +static int cdns_i3c_gpio_get_direction(struct gpio_chip *g, unsigned offset)
> +{
> + struct cdns_i3c_gpio *gpioc = gpioc_to_cdns_gpioc(g);
> +
> + return gpioc->dir & BIT(offset);
I would:
return !!(gpioc->dir & BIT(offset));
So you clamp it to bit 0.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] powerpc: use task_pid_nr() for TID allocation
On 25/04/18 07:12, Sukadev Bhattiprolu wrote: Yes. Like with PIDR, was trying to assign TIDR initially to all threads. But since only a subset of threads need/use TIDR, we can assign the value later (when set_thread_tidr() is called). So we should be able to use task_pid_nr() then. OK. Alastair has also confirmed with me that truncating the pid to a u16 should be safe, so therefore: Reviewed-by: Andrew Donnellan -- Andrew Donnellan OzLabs, ADL Canberra andrew.donnel...@au1.ibm.com IBM Australia Limited -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] ThunderX2: Add Cavium ThunderX2 SoC UNCORE PMU driver
Hi,
On Wed, Apr 25, 2018 at 02:30:47PM +0530, Ganapatrao Kulkarni wrote:
> +
> +/* L3c and DMC has 16 and 8 channels per socket respectively.
> + * Each Channel supports UNCORE PMU device and consists of
> + * 4 independent programmable counters. Counters are 32 bit
> + * and does not support overflow interrupt, they needs to be
> + * sampled before overflow(i.e, at every 2 seconds).
> + */
> +
> +#define UNCORE_MAX_COUNTERS 4
> +#define UNCORE_L3_MAX_TILES 16
> +#define UNCORE_DMC_MAX_CHANNELS 8
> +
> +#define UNCORE_HRTIMER_INTERVAL (2 * NSEC_PER_SEC)
How was a period of two seconds chosen?
What's the maximum clock speed for the L3C and DMC?
Given that all channels compete for access to the muxed register
interface, I suspect we need to try more often than once every 2
seconds...
[...]
> +struct active_timer {
> + struct perf_event *event;
> + struct hrtimer hrtimer;
> +};
> +
> +/*
> + * pmu on each socket has 2 uncore devices(dmc and l3),
> + * each uncore device has up to 16 channels, each channel can sample
> + * events independently with counters up to 4.
> + *
> + * struct thunderx2_pmu_uncore_channel created per channel.
> + * struct thunderx2_pmu_uncore_dev per uncore device.
> + */
> +struct thunderx2_pmu_uncore_channel {
> + struct thunderx2_pmu_uncore_dev *uncore_dev;
> + struct pmu pmu;
Can we put the pmu first in the struct, please?
> + int counter;
AFAICT, this counter field is never used.
> + int channel;
> + DECLARE_BITMAP(counter_mask, UNCORE_MAX_COUNTERS);
> + struct active_timer *active_timers;
You should only need a single timer per channel, rather than one per
event.
I think you can get rid of the active_timer structure, and have:
struct perf_event *events[UNCORE_MAX_COUNTERS];
struct hrtimer timer;
> + /* to sync counter alloc/release */
> + raw_spinlock_t lock;
> +};
> +
> +struct thunderx2_pmu_uncore_dev {
> + char *name;
> + struct device *dev;
> + enum thunderx2_uncore_type type;
> + unsigned long base;
This should be:
void __iomem *base;
[...]
> +static ssize_t cpumask_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct cpumask cpu_mask;
> + struct thunderx2_pmu_uncore_channel *pmu_uncore =
> + pmu_to_thunderx2_pmu_uncore(dev_get_drvdata(dev));
> +
> + /* Pick first online cpu from the node */
> + cpumask_clear(&cpu_mask);
> + cpumask_set_cpu(cpumask_first(
> + cpumask_of_node(pmu_uncore->uncore_dev->node)),
> + &cpu_mask);
> +
> + return cpumap_print_to_pagebuf(true, buf, &cpu_mask);
> +}
AFAICT cpumask_of_node() returns a mask that can include offline CPUs.
Regardless, I don't think that you can keep track of the management CPU
this way. Please keep track of the CPU the PMU should be managed by,
either with a cpumask or int embedded within the PMU structure.
At hotplug time, you'll need to update the management CPU, calling
perf_pmu_migrate_context() when it is offlined.
[...]
> +static int alloc_counter(struct thunderx2_pmu_uncore_channel *pmu_uncore)
> +{
> + int counter;
> +
> + raw_spin_lock(&pmu_uncore->lock);
> + counter = find_first_zero_bit(pmu_uncore->counter_mask,
> + pmu_uncore->uncore_dev->max_counters);
> + if (counter == pmu_uncore->uncore_dev->max_counters) {
> + raw_spin_unlock(&pmu_uncore->lock);
> + return -ENOSPC;
> + }
> + set_bit(counter, pmu_uncore->counter_mask);
> + raw_spin_unlock(&pmu_uncore->lock);
> + return counter;
> +}
> +
> +static void free_counter(struct thunderx2_pmu_uncore_channel *pmu_uncore,
> + int counter)
> +{
> + raw_spin_lock(&pmu_uncore->lock);
> + clear_bit(counter, pmu_uncore->counter_mask);
> + raw_spin_unlock(&pmu_uncore->lock);
> +}
I don't believe that locking is required in either of these, as the perf
core serializes pmu::add() and pmu::del(), where these get called.
> +
> +/*
> + * DMC and L3 counter interface is muxed across all channels.
> + * hence we need to select the channel before accessing counter
> + * data/control registers.
Are there separate interfaces for all-dmc-channels and all-l3c-channels?
... or is a single interface used by all-dmc-and-l3c-channels?
> + *
> + * L3 Tile and DMC channel selection is through SMC call
> + * SMC call arguments,
> + * x0 = THUNDERX2_SMC_CALL_ID (Vendor SMC call Id)
> + * x1 = THUNDERX2_SMC_SET_CHANNEL (Id to set DMC/L3C channel)
> + * x2 = Node id
How do we map Linux node IDs to the firmware's view of node IDs?
I don't believe the two are necessarily the same -- Linux's node IDs are
a Linux-specific construct.
It would be much nicer if we could pass something based on the MPIDR,
which is a known HW construct, or if this implicitly affected the
current no
Re: [PATCH v2] gpiolib: add hogs support for machine code
On Tue, Apr 10, 2018 at 10:30 PM, Bartosz Golaszewski wrote: > Board files constitute a significant part of the users of the legacy > GPIO framework. In many cases they only export a line and set its > desired value. We could use GPIO hogs for that like we do for DT and > ACPI but there's no support for that in machine code. > > This patch proposes to extend the machine.h API with support for > registering hog tables in board files. > > Signed-off-by: Bartosz Golaszewski > --- > v1 -> v2: > - kbuild bot complains about enum gpiod_flags having incomplete type > although it builds fine for me locally: change the type of dflags > to int I like the idea and thinking behind this patch, so patch applied. It's a bit of code to carry, so if it doesn't see any use, I will simply revert it :) But I bet you intend to follow up with some machine patches and then it is immediately worth it. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gpiolib: add hogs support for machine code
On Thu, Apr 12, 2018 at 10:00 PM, Christian Lamparter wrote: > The problem is that unlike native gpio-controllers, pinctrls need > to have a "pin/gpio range" defined before any gpio-hogs can be added. Indeed. But the primary use case (correct me if I am wrong Bartosz) is to clean up old boardfile code. Old boardfiles belong to equally old boards. They very often do not have pin control, just GPIO, and they very often have custom code that just issue gpio_get(), gpio_* etc to set up hogs. So this will be able to replace all such boilerplate with some hog table for each boardfile and be done with it. I.e. they have only drivers/gpio/gpio-foo.c and no pin control driver in 9 cases out of 10. Cases do exist where they use pin control with board files. Those are rare. But they will have problems. Some machine descriptor tables are used on modern archs and the most prominent is x86 Intel. However the Intel pin control driver is one of those that (IIRC) will actually survive this (i.e. it doesn not have this bug). They are not even using DT, they use ACPI. > So what will happen is that you'll get an > "gpiochip_machine_hog: unable to hog GPIO line $LABEL $GPIONR -517" error > for every single gpio-hog and wonder why :(. Hm maybe we can simply improbe the error messages so people realize they have to go and fix their pin control driver(s)? OK maybe a bit whimsical comment from me here... :/ Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 01/10] PCI: dwc: Add MSI-X callbacks handler
Hi Kishon,
On 24/04/2018 12:24, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Tuesday 24 April 2018 03:06 PM, Gustavo Pimentel wrote:
>> Hi Kishon,
>>
>> On 24/04/2018 08:07, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
>>> On Monday 23 April 2018 03:06 PM, Gustavo Pimentel wrote:
Hi Kishon,
On 16/04/2018 10:29, Kishon Vijay Abraham I wrote:
> Hi Gustavo,
>
> On Tuesday 10 April 2018 10:44 PM, Gustavo Pimentel wrote:
>> Changes the pcie_raise_irq function signature, namely the interrupt_num
>> variable type from u8 to u16 to accommodate the MSI-X maximum interrupts
>> of 2048.
>>
>> Implements a PCIe config space capability iterator function to search and
>> save the MSI and MSI-X pointers. With this method the code becomes more
>> generic and flexible.
>>
>> Implements MSI-X set/get functions for sysfs interface in order to change
>> the EP entries number.
>>
>> Implements EP MSI-X interface for triggering interruptions.
>>
>> Signed-off-by: Gustavo Pimentel
>> ---
>> drivers/pci/dwc/pci-dra7xx.c | 2 +-
>> drivers/pci/dwc/pcie-artpec6.c | 2 +-
>> drivers/pci/dwc/pcie-designware-ep.c | 145
>> -
>> drivers/pci/dwc/pcie-designware-plat.c | 6 +-
>> drivers/pci/dwc/pcie-designware.h | 23 +-
>> 5 files changed, 173 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
>> index ed8558d..5265725 100644
>> --- a/drivers/pci/dwc/pci-dra7xx.c
>> +++ b/drivers/pci/dwc/pci-dra7xx.c
>> @@ -369,7 +369,7 @@ static void dra7xx_pcie_raise_msi_irq(struct
>> dra7xx_pcie *dra7xx,
>> }
>>
>> static int dra7xx_pcie_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
>> - enum pci_epc_irq_type type, u8
>> interrupt_num)
>> + enum pci_epc_irq_type type, u16
>> interrupt_num)
>> {
>> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>> struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pci);
>> diff --git a/drivers/pci/dwc/pcie-artpec6.c
>> b/drivers/pci/dwc/pcie-artpec6.c
>> index e66cede..96dc259 100644
>> --- a/drivers/pci/dwc/pcie-artpec6.c
>> +++ b/drivers/pci/dwc/pcie-artpec6.c
>> @@ -428,7 +428,7 @@ static void artpec6_pcie_ep_init(struct dw_pcie_ep
>> *ep)
>> }
>>
>> static int artpec6_pcie_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
>> - enum pci_epc_irq_type type, u8
>> interrupt_num)
>> + enum pci_epc_irq_type type, u16
>> interrupt_num)
>> {
>> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>>
>> diff --git a/drivers/pci/dwc/pcie-designware-ep.c
>> b/drivers/pci/dwc/pcie-designware-ep.c
>> index 15b22a6..874d4c2 100644
>> --- a/drivers/pci/dwc/pcie-designware-ep.c
>> +++ b/drivers/pci/dwc/pcie-designware-ep.c
>> @@ -40,6 +40,44 @@ void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum
>> pci_barno bar)
>> __dw_pcie_ep_reset_bar(pci, bar, 0);
>> }
>>
>> +void dw_pcie_ep_find_cap_addr(struct dw_pcie_ep *ep)
>> +{
>
> This should be implemented in a generic way similar to
> pci_find_capability().
> It'll be useful when we try to implement other capabilities as well.
Hum, what you suggest? Something implemented on the pci-epf-core?
>>>
>>> yeah, Initially thought it could be implemented as a helper function in
>>> pci-epc-core so that both designware and cadence can use it.
>>
>> That would be nice, however I couldn't find out how to access the config
>> space,
>> through the pci_epf or pci_epc structs.
>
> It's just a helper function so it can directly take the base address of the
> configuration space as argument (in our case, it should be dbi_base).
I don't think it will bring much benefit to this particular scope at this time
being. In any case this could be improved later.
Regards,
Gustavo
>
> Thanks
> Kishon
>
>>
>> So, I reworked the functions like this:
>>
>> (on pcie-designware-ep.c)
>>
>> u8 __dw_pcie_ep_find_next_cap(struct dw_pcie *pci, u8 cap_ptr,
>> u8 cap)
>> {
>> u8 cap_id, next_cap_ptr;
>> u16 reg;
>>
>> reg = dw_pcie_readw_dbi(pci, cap_ptr);
>> next_cap_ptr = (reg & 0xff00) >> 8;
>> cap_id = (reg & 0x00ff);
>>
>> if (!next_cap_ptr || cap_id > PCI_CAP_ID_MAX)
>> return 0;
>>
>> if (cap_id == cap)
>> return cap_ptr;
>>
>> return __dw_pcie_ep_find_next_cap(pci, next_cap_ptr, cap);
>> }
>>
>> u8 dw_pcie_ep_find_capability(struct dw_pcie *pci, u8 cap)
>> {
>> u8 next_cap_ptr;
>> u16 reg;
>>
>> reg = dw_pcie_readw_dbi(pci, PCI_CAPABILITY_LIST);
>
Re: [RFC 06/10] misc: pci_endpoint_test: Add MSI-X support
Hi Kishon, On 24/04/2018 12:43, Kishon Vijay Abraham I wrote: > Hi, > > On Tuesday 24 April 2018 04:27 PM, Gustavo Pimentel wrote: >> Hi Kishon, >> >> On 24/04/2018 08:19, Kishon Vijay Abraham I wrote: >>> Hi, >>> >>> On Tuesday 17 April 2018 11:08 PM, Gustavo Pimentel wrote: Hi Kishon, On 17/04/2018 11:33, Kishon Vijay Abraham I wrote: > Hi, > > On Tuesday 10 April 2018 10:44 PM, Gustavo Pimentel wrote: >> Adds the MSI-X support and updates driver documentation accordingly. >> >> Changes the driver parameter in order to allow the interruption type >> selection. >> >> Signed-off-by: Gustavo Pimentel >> --- >> Documentation/misc-devices/pci-endpoint-test.txt | 3 + >> drivers/misc/pci_endpoint_test.c | 102 >> +-- >> 2 files changed, 79 insertions(+), 26 deletions(-) >> >> diff --git a/Documentation/misc-devices/pci-endpoint-test.txt >> b/Documentation/misc-devices/pci-endpoint-test.txt >> index 4ebc359..fdfa0f6 100644 >> --- a/Documentation/misc-devices/pci-endpoint-test.txt >> +++ b/Documentation/misc-devices/pci-endpoint-test.txt >> @@ -10,6 +10,7 @@ The PCI driver for the test device performs the >> following tests >> *) verifying addresses programmed in BAR >> *) raise legacy IRQ >> *) raise MSI IRQ >> +*) raise MSI-X IRQ >> *) read data >> *) write data >> *) copy data >> @@ -25,6 +26,8 @@ ioctl >> PCITEST_LEGACY_IRQ: Tests legacy IRQ >> PCITEST_MSI: Tests message signalled interrupts. The MSI number >>to be tested should be passed as argument. >> + PCITEST_MSIX: Tests message signalled interrupts. The MSI-X number >> + to be tested should be passed as argument. >> PCITEST_WRITE: Perform write tests. The size of the buffer should be >> passed >> as argument. >> PCITEST_READ: Perform read tests. The size of the buffer should be >> passed >> diff --git a/drivers/misc/pci_endpoint_test.c >> b/drivers/misc/pci_endpoint_test.c >> index 37db0fc..a7d9354 100644 >> --- a/drivers/misc/pci_endpoint_test.c >> +++ b/drivers/misc/pci_endpoint_test.c >> @@ -42,11 +42,16 @@ >> #define PCI_ENDPOINT_TEST_COMMAND 0x4 >> #define COMMAND_RAISE_LEGACY_IRQBIT(0) >> #define COMMAND_RAISE_MSI_IRQ BIT(1) >> -#define MSI_NUMBER_SHIFT2 >> -/* 6 bits for MSI number */ >> -#define COMMAND_READBIT(8) >> -#define COMMAND_WRITE BIT(9) >> -#define COMMAND_COPYBIT(10) >> +#define COMMAND_RAISE_MSIX_IRQ BIT(2) >> +#define IRQ_TYPE_SHIFT 3 >> +#define IRQ_TYPE_LEGACY 0 >> +#define IRQ_TYPE_MSI1 >> +#define IRQ_TYPE_MSIX 2 >> +#define MSI_NUMBER_SHIFT5 > > Now that you are anyways fixing this, add a new register entry for MSI > numbers. > Let's not keep COMMAND and MSI's together. What you suggest? >>> >>> #define PCI_ENDPOINT_TEST_COMMAND 0x4 >>> #define COMMAND_RAISE_LEGACY_IRQBIT(0) >>> #define COMMAND_RAISE_MSI_IRQ BIT(1) >>> #define COMMAND_RAISE_MSIX_IRQ BIT(2) >>> #define COMMAND_READBIT(3) >>> #define COMMAND_WRITE BIT(4) >>> #define COMMAND_COPYBIT(5) >>> >>> #define PCI_ENDPOINT_TEST_STATUS0x8 >>> #define STATUS_READ_SUCCESS BIT(0) >>> #define STATUS_READ_FAILBIT(1) >>> #define STATUS_WRITE_SUCCESSBIT(2) >>> #define STATUS_WRITE_FAIL BIT(3) >>> #define STATUS_COPY_SUCCESS BIT(4) >>> #define STATUS_COPY_FAILBIT(5) >>> #define STATUS_IRQ_RAISED BIT(6) >>> #define STATUS_SRC_ADDR_INVALID BIT(7) >>> #define STATUS_DST_ADDR_INVALID BIT(8) >>> >>> #define PCI_ENDPOINT_TEST_LOWER_SRC_ADDR0xc >>> #define PCI_ENDPOINT_TEST_UPPER_SRC_ADDR0x10 >>> >>> #define PCI_ENDPOINT_TEST_LOWER_DST_ADDR0x14 >>> #define PCI_ENDPOINT_TEST_UPPER_DST_ADDR0x18 >>> >>> #define PCI_ENDPOINT_TEST_SIZE 0x1c >>> #define PCI_ENDPOINT_TEST_CHECKSUM 0x20 >>> >>> #define PCI_ENDPOINT_TEST_MSI_NUMBER0x24 >> >> Ok. I will do it. >> >>> >>> We should try not to modify either the existing register offsets or the bit >>> fields within these registers in the future as EP and RC will be running on >>> different systems and it is possible one of them might not have the updated >>> kernel. >> >> I totally agree. >> >> +/* 12 bits for MSI number */ >> +#define COMMAND_READBIT(17) >> +#define COMMAND_WRITE BIT(18) >> +#define COMMAND_COPY
Re: [PATCH 3/6] arm64: untag user addresses in copy_from_user and others
On Wed, Apr 18, 2018 at 08:53:12PM +0200, Andrey Konovalov wrote:
> @@ -238,12 +239,15 @@ static inline void uaccess_enable_not_uao(void)
> /*
> * Sanitise a uaccess pointer such that it becomes NULL if above the
> * current addr_limit.
> + * Also untag user pointers that have the top byte tag set.
> */
> #define uaccess_mask_ptr(ptr) (__typeof__(ptr))__uaccess_mask_ptr(ptr)
> static inline void __user *__uaccess_mask_ptr(const void __user *ptr)
> {
> void __user *safe_ptr;
>
> + ptr = untagged_addr(ptr);
> +
> asm volatile(
> " bicsxzr, %1, %2\n"
> " csel%0, %1, xzr, eq\n"
First of all, passing a tagged user pointer throughout the kernel is
safe with uaccess routines but not suitable for find_vma() etc.
With this change, we may have an inconsistent behaviour on the tag
masking, depending on whether the entry code uses __uaccess_mask_ptr()
or not. We could preserve the tag with something like:
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index e66b0fca99c2..ed15bfcbd797 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -244,10 +244,11 @@ static inline void __user *__uaccess_mask_ptr(const void
__user *ptr)
void __user *safe_ptr;
asm volatile(
- " bicsxzr, %1, %2\n"
+ " bicsxzr, %3, %2\n"
" csel%0, %1, xzr, eq\n"
: "=&r" (safe_ptr)
- : "r" (ptr), "r" (current_thread_info()->addr_limit)
+ : "r" (ptr), "r" (current_thread_info()->addr_limit),
+ "r" (untagged_addr(ptr))
: "cc");
csdb();
--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gpiolib: add hogs support for machine code
2018-04-26 14:07 GMT+02:00 Linus Walleij : > On Tue, Apr 10, 2018 at 10:30 PM, Bartosz Golaszewski wrote: > >> Board files constitute a significant part of the users of the legacy >> GPIO framework. In many cases they only export a line and set its >> desired value. We could use GPIO hogs for that like we do for DT and >> ACPI but there's no support for that in machine code. >> >> This patch proposes to extend the machine.h API with support for >> registering hog tables in board files. >> >> Signed-off-by: Bartosz Golaszewski >> --- >> v1 -> v2: >> - kbuild bot complains about enum gpiod_flags having incomplete type >> although it builds fine for me locally: change the type of dflags >> to int > > I like the idea and thinking behind this patch, so patch applied. > > It's a bit of code to carry, so if it doesn't see any use, I will simply > revert it :) > > But I bet you intend to follow up with some machine patches > and then it is immediately worth it. Yes, I'll be submitting patches removing the legacy gpio calls for boards in mach-davinci. Thanks, Bartosz -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] mm, arm64: untag user addresses in mm/gup.c
On Wed, Apr 18, 2018 at 08:53:13PM +0200, Andrey Konovalov wrote:
> diff --git a/mm/gup.c b/mm/gup.c
> index 76af4cfeaf68..fb375de7d40d 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -386,6 +386,8 @@ struct page *follow_page_mask(struct vm_area_struct *vma,
> struct page *page;
> struct mm_struct *mm = vma->vm_mm;
>
> + address = untagged_addr(address);
> +
> *page_mask = 0;
>
> /* make this handle hugepd */
Does having a tagged address here makes any difference? I couldn't hit a
failure with my simple tests (LD_PRELOAD a library that randomly adds
tags to pointers returned by malloc).
> @@ -647,6 +649,8 @@ static long __get_user_pages(struct task_struct *tsk,
> struct mm_struct *mm,
> if (!nr_pages)
> return 0;
>
> + start = untagged_addr(start);
> +
> VM_BUG_ON(!!pages != !!(gup_flags & FOLL_GET));
>
> /*
> @@ -801,6 +805,8 @@ int fixup_user_fault(struct task_struct *tsk, struct
> mm_struct *mm,
> struct vm_area_struct *vma;
> int ret, major = 0;
>
> + address = untagged_addr(address);
> +
> if (unlocked)
> fault_flags |= FAULT_FLAG_ALLOW_RETRY;
>
> @@ -854,6 +860,8 @@ static __always_inline long
> __get_user_pages_locked(struct task_struct *tsk,
> long ret, pages_done;
> bool lock_dropped;
>
> + start = untagged_addr(start);
> +
> if (locked) {
> /* if VM_FAULT_RETRY can be returned, vmas become invalid */
> BUG_ON(vmas);
Isn't __get_user_pages() untagging enough to cover this case as well?
Can this function not cope with tagged pointers?
> @@ -1751,6 +1759,8 @@ int __get_user_pages_fast(unsigned long start, int
> nr_pages, int write,
> unsigned long flags;
> int nr = 0;
>
> + start = untagged_addr(start);
> +
> start &= PAGE_MASK;
> addr = start;
> len = (unsigned long) nr_pages << PAGE_SHIFT;
> @@ -1803,6 +1813,8 @@ int get_user_pages_fast(unsigned long start, int
> nr_pages, int write,
> unsigned long addr, len, end;
> int nr = 0, ret = 0;
>
> + start = untagged_addr(start);
> +
> start &= PAGE_MASK;
> addr = start;
> len = (unsigned long) nr_pages << PAGE_SHIFT;
Have you hit a problem with the fast gup functions and tagged pointers?
The page table walking macros (e.g. p*d_index()) should mask the tag out
already.
--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] arm64: untag user pointers passed to the kernel
On Wed, Apr 25, 2018 at 04:45:37PM +0200, Andrey Konovalov wrote: > On Thu, Apr 19, 2018 at 11:33 AM, Kirill A. Shutemov > wrote: > > On Wed, Apr 18, 2018 at 08:53:09PM +0200, Andrey Konovalov wrote: > >> arm64 has a feature called Top Byte Ignore, which allows to embed pointer > >> tags into the top byte of each pointer. Userspace programs (such as > >> HWASan, a memory debugging tool [1]) might use this feature and pass > >> tagged user pointers to the kernel through syscalls or other interfaces. > >> > >> This patch makes a few of the kernel interfaces accept tagged user > >> pointers. The kernel is already able to handle user faults with tagged > >> pointers and has the untagged_addr macro, which this patchset reuses. > >> > >> We're not trying to cover all possible ways the kernel accepts user > >> pointers in one patchset, so this one should be considered as a start. > > > > How many changes do you anticipate? > > > > This patchset looks small and reasonable, but I see a potential to become a > > boilerplate. Would we need to change every driver which implements ioctl() > > to strip these bits? > > I've replied to somewhat similar question in one of the previous > versions of the patchset. > > """ > There are two different approaches to untagging the user pointers that I see: > > 1. Untag user pointers right after they are passed to the kernel. > > While this might be possible for pointers that are passed to syscalls > as arguments (Catalin's "hack"), this leaves user pointers, that are > embedded into for example structs that are passed to the kernel. Since > there's no specification of the interface between user space and the > kernel, different kernel parts handle user pointers differently and I > don't see an easy way to cover them all. > > 2. Untag user pointers where they are used in the kernel. > > Although there's no specification on the interface between the user > space and the kernel, the kernel still has to use one of a few > specific ways to access user data (copy_from_user, etc.). So the idea > here is to add untagging into them. This patchset mostly takes this > approach (with the exception of memory subsystem syscalls). > > If there's a better approach, I'm open to suggestions. > """ > > So if we go with the first way, we'll need to go through every syscall > and ioctl handler, which doesn't seem feasible. I agree with you that (1) isn't feasible. My hack is sufficient for the pointer arguments but doesn't help with pointers in user structures passed to the kernel. Now, since the hardware allows access to user pointers with non-zero top 8-bit, the kernel uaccess routines can also use such pointers directly. What's needed, as per your patches, is the access_ok() macro and whatever ends up calling find_vma() (at a first look, there may be other cases). I don't think drivers need changing as long as the in-kernel API they use performs the untagging (e.g. get_user_pages()). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] perf: uncore: Adding documentation for ThunderX2 pmu uncore driver
Hi, Just a few typo corrections... On 04/25/2018 02:00 AM, Ganapatrao Kulkarni wrote: > Documentation for the UNCORE PMUs on Cavium's ThunderX2 SoC. > The SoC has PMU support in its L3 cache controller (L3C) and in the > DDR4 Memory Controller (DMC). > > Signed-off-by: Ganapatrao Kulkarni > --- > Documentation/perf/thunderx2-pmu.txt | 66 > > 1 file changed, 66 insertions(+) > create mode 100644 Documentation/perf/thunderx2-pmu.txt > > diff --git a/Documentation/perf/thunderx2-pmu.txt > b/Documentation/perf/thunderx2-pmu.txt > new file mode 100644 > index 000..9e9f535 > --- /dev/null > +++ b/Documentation/perf/thunderx2-pmu.txt > @@ -0,0 +1,66 @@ > + > +Cavium ThunderX2 SoC Performance Monitoring Unit (PMU UNCORE) > +== > + > +ThunderX2 SoC PMU consists of independent system wide per Socket PMUs such > +as Level 3 Cache(L3C) and DDR4 Memory Controller(DMC). > + > +It has 8 independent DMC PMUs to capture performance events corresponding > +to 8 channels of DDR4 Memory Controller. There are 16 independent L3C PMUs > +to capture events corresponding to 16 tiles of L3 cache. Each PMU supports > +up to 4 counters. > + > +Counters are independent programmable and can be started and stopped independently > +individually. Each counter can be set to sample specific perf events. > +Counters are 32 bit and does not support overflow interrupt, they are do notinterrupt; they are > +sampled at every 2 seconds. The Counters register access are multiplexed > +across channels of DMC and L3C. The muxing(select channel) is done through > +write to a Secure register using smcc calls. > + > +PMU UNCORE (perf) driver: > + > +The thunderx2-pmu driver registers several perf PMUs for DMC and L3C devices. > +Each of the PMU provides description of its available events of the PMUs > +and configuration options in sysfs. > + see /sys/devices/uncore_ > + > +S is socket id and X represents channel number. > +Each PMU can be used to sample up to 4 events simultaneously. > + > +The "format" directory describes format of the config (event ID). > +The "events" directory provides configuration templates for all > +supported event types that can be used with perf tool. > + > +For example, "uncore_dmc_0_0/cnt_cycles/" is an > +equivalent of "uncore_dmc_0_0/config=0x1/". > + > +Each perf driver also provides a "cpumask" sysfs attribute, which contains a > +single CPU ID of the processor which is likely to be used to handle all the > +PMU events. It will be the first online CPU from the NUMA node of PMU device. > + > +Example for perf tool use: > + > +perf stat -a -e \ > +uncore_dmc_0_0/cnt_cycles/,\ > +uncore_dmc_0_1/cnt_cycles/,\ > +uncore_dmc_0_2/cnt_cycles/,\ > +uncore_dmc_0_3/cnt_cycles/,\ > +uncore_dmc_0_4/cnt_cycles/,\ > +uncore_dmc_0_5/cnt_cycles/,\ > +uncore_dmc_0_6/cnt_cycles/,\ > +uncore_dmc_0_7/cnt_cycles/ sleep 1 > + > +perf stat -a -e \ > +uncore_dmc_0_0/cancelled_read_txns/,\ > +uncore_dmc_0_0/cnt_cycles/,\ > +uncore_dmc_0_0/consumed_read_txns/,\ > +uncore_dmc_0_0/data_transfers/ sleep 1 > + > +perf stat -a -e \ > +uncore_l3c_0_0/l3_retry/,\ > +uncore_l3c_0_0/read_hit/,\ > +uncore_l3c_0_0/read_request/,\ > +uncore_l3c_0_0/inv_request/ sleep 1 > + > +The driver does not support sampling, therefore "perf record" will > +not work. Per-task (without "-a") perf sessions are not supported. > -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v3] docs: kernel-parameters.txt: Fix whitespace
Some lines used spaces instead of tabs at line start.
This can cause mangled lines in editors due to inconsistency.
Replace spaces for tabs where appropriate.
Signed-off-by: Thymo van Beers
Reviewed-by: Randy Dunlap
---
Changes in v3:
- Change indentation in intel_pstate to reduce overrunning 80-column
mark
- Indent "nohrst, nosrst, norst:" like "rstonce"
Changes in v2:
- Rebase against docs-next
- Fix indentation modifications
Documentation/admin-guide/kernel-parameters.txt | 136
1 file changed, 68 insertions(+), 68 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 3487be79847c..865a24e4d516 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -106,11 +106,11 @@
use by PCI
Format: ,...
- acpi_mask_gpe= [HW,ACPI]
+ acpi_mask_gpe= [HW,ACPI]
Due to the existence of _Lxx/_Exx, some GPEs triggered
by unsupported hardware/firmware features can result in
-GPE floodings that cannot be automatically disabled by
-the GPE dispatcher.
+ GPE floodings that cannot be automatically disabled by
+ the GPE dispatcher.
This facility can be used to prevent such uncontrolled
GPE floodings.
Format:
@@ -472,10 +472,10 @@
for platform specific values (SB1, Loongson3 and
others).
- ccw_timeout_log [S390]
+ ccw_timeout_log [S390]
See Documentation/s390/CommonIO for details.
- cgroup_disable= [KNL] Disable a particular controller
+ cgroup_disable= [KNL] Disable a particular controller
Format: {name of the controller(s) to disable}
The effects of cgroup_disable=foo are:
- foo isn't auto-mounted if you mount all cgroups in
@@ -641,8 +641,8 @@
hvc Use the hypervisor console device . This is for
both Xen and PowerPC hypervisors.
-If the device connected to the port is not a TTY but a braille
-device, prepend "brl," before the device type, for instance
+ If the device connected to the port is not a TTY but a braille
+ device, prepend "brl," before the device type, for instance
console=brl,ttyS0
For now, only VisioBraille is supported.
@@ -662,7 +662,7 @@
consoleblank= [KNL] The console blank (screen saver) timeout in
seconds. A value of 0 disables the blank timer.
- Defaults to 0.
+ Defaults to 0.
coredump_filter=
[KNL] Change the default value for
@@ -730,7 +730,7 @@
or memory reserved is below 4G.
cryptomgr.notests
-[KNL] Disable crypto self-tests
+ [KNL] Disable crypto self-tests
cs89x0_dma= [HW,NET]
Format:
@@ -746,7 +746,7 @@
Format: ,
See also
Documentation/input/devices/joystick-parport.rst
- ddebug_query= [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot
+ ddebug_query= [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot
time. See
Documentation/admin-guide/dynamic-debug-howto.rst for
details. Deprecated, see dyndbg.
@@ -833,7 +833,7 @@
causing system reset or hang due to sending
INIT from AP to BSP.
- disable_ddw [PPC/PSERIES]
+ disable_ddw [PPC/PSERIES]
Disable Dynamic DMA Window support. Use this if
to workaround buggy firmware.
@@ -1188,7 +1188,7 @@
parameter will force ia64_sal_cache_flush to call
ia64_pal_cache_flush instead of SAL_CACHE_FLUSH.
- forcepae [X86-32]
+ forcepae[X86-32]
Forcefully enable Physical Address Extension (PAE).
Many Pentium M systems disable PAE but may have a
functionally usable PAE implementation.
@@ -1247,7 +1247,7 @@
gamma= [HW,DRM]
- gart_fix_e820= [X86_64] disable the fix e820 for K8 GART
+ gart_fix_e820= [X86_64] disable the fix e820 for K8 GART
Format: off | on
default: on
@@ -1341,11 +1341,11 @@
x86-64 are 2M (when the CPU supports "pse") and 1G
(when the CPU supp
Re: [PATCH v4 2/2] ThunderX2: Add Cavium ThunderX2 SoC UNCORE PMU driver
On Wed, 25 Apr 2018 14:30:47 +0530 Ganapatrao Kulkarni wrote: > +static int thunderx2_uncore_event_init(struct perf_event *event) ... > + /* > + * SOC PMU counters are shared across all cores. > + * Therefore, it does not support per-process mode. > + * Also, it does not support event sampling mode. > + */ > + if (is_sampling_event(event) || event->attach_state & PERF_ATTACH_TASK) > + return -EINVAL; > + > + /* SOC counters do not have usr/os/guest/host bits */ > + if (event->attr.exclude_user || event->attr.exclude_kernel || > + event->attr.exclude_host || event->attr.exclude_guest) > + return -EINVAL; > + > + if (event->cpu < 0) > + return -EINVAL; > + > + pmu_uncore = pmu_to_thunderx2_pmu_uncore(event->pmu); > + > + if (!pmu_uncore) > + return -ENODEV; > + > + /* Pick first online cpu from the node */ > + event->cpu = cpumask_first( > + cpumask_of_node(pmu_uncore->uncore_dev->node)); > + > + if (event->cpu >= nr_cpu_ids) > + return -EINVAL; > + > + if (event->attr.config >= pmu_uncore->uncore_dev->max_events) > + return -EINVAL; > + > + /* store event id */ > + hwc->config = event->attr.config; > + > + /* Validate the group */ > + if (!thunderx2_uncore_validate_event_group(event)) > + return -EINVAL; This PMU driver can be made more user-friendly by not just silently returning an error code such as -EINVAL, but by emitting a useful message describing the specific error via dmesg. Thanks, Kim -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] documentation: core-api: rearrange a few kernel-api chapters and sections
From: Randy Dunlap Rearrange some kernel-api chapters and sections to group them together better. - move Bit Operations from Basic C Library Functions to Basic Kernel Library Functions (now adjacent to Bitmap Operations since they are not typical C library functions) - move Sorting from Math Functions to Basic Kernel Library Functions since sort functions are more Basic than Math Functions - move Text Searching from Math Functions to Basic Kernel Library Functions (keep Sorting and Searching close to each other) - combine CRC and Math functions together into the (newly named) CRC and Math Functions chapter Signed-off-by: Randy Dunlap --- Documentation/core-api/kernel-api.rst | 60 1 file changed, 30 insertions(+), 30 deletions(-) --- linux-next-20180426.orig/Documentation/core-api/kernel-api.rst +++ linux-next-20180426/Documentation/core-api/kernel-api.rst @@ -39,17 +39,17 @@ String Manipulation .. kernel-doc:: lib/string.c :export: +Basic Kernel Library Functions +== + +The Linux kernel provides more basic utility functions. + Bit Operations -- .. kernel-doc:: arch/x86/include/asm/bitops.h :internal: -Basic Kernel Library Functions -== - -The Linux kernel provides more basic utility functions. - Bitmap Operations - @@ -80,6 +80,31 @@ Command-line Parsing .. kernel-doc:: lib/cmdline.c :export: +Sorting +--- + +.. kernel-doc:: lib/sort.c + :export: + +.. kernel-doc:: lib/list_sort.c + :export: + +Text Searching +-- + +.. kernel-doc:: lib/textsearch.c + :doc: ts_intro + +.. kernel-doc:: lib/textsearch.c + :export: + +.. kernel-doc:: include/linux/textsearch.h + :functions: textsearch_find textsearch_next \ + textsearch_get_pattern textsearch_get_pattern_len + +CRC and Math Functions in Linux +=== + CRC Functions - @@ -103,9 +128,6 @@ CRC Functions .. kernel-doc:: lib/crc-itu-t.c :export: -Math Functions in Linux -=== - Base 2 log and power Functions -- @@ -127,28 +149,6 @@ Division Functions .. kernel-doc:: lib/gcd.c :export: -Sorting - -.. kernel-doc:: lib/sort.c - :export: - -.. kernel-doc:: lib/list_sort.c - :export: - -Text Searching --- - -.. kernel-doc:: lib/textsearch.c - :doc: ts_intro - -.. kernel-doc:: lib/textsearch.c - :export: - -.. kernel-doc:: include/linux/textsearch.h - :functions: textsearch_find textsearch_next \ - textsearch_get_pattern textsearch_get_pattern_len - UUID/GUID - -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] fpga: region: change api, add fpga_region_create/free
From: Alan Tull
Add fpga_region_create/free API functions.
Change fpga_region_register to take FPGA region struct as the only
parameter. Change fpga_region_unregister to return void.
struct fpga_region *fpga_region_create(struct device *dev,
struct fpga_manager *mgr,
int (*get_bridges)(struct fpga_region *));
void fpga_region_free(struct fpga_region *region);
int fpga_region_register(struct fpga_region *region);
void fpga_region_unregister(struct fpga_region *region);
Remove groups storage from struct fpga_region, it's not
needed. Callers can just "region->dev.groups = groups;"
after calling fpga_region_create.
Update the drivers that call fpga_region_register with the new API.
Signed-off-by: Alan Tull
Signed-off-by: Moritz Fischer
---
Documentation/fpga/fpga-region.txt | 3 +-
drivers/fpga/fpga-region.c | 68 --
drivers/fpga/of-fpga-region.c | 13 +++---
include/linux/fpga/fpga-region.h | 11 +++--
4 files changed, 68 insertions(+), 27 deletions(-)
diff --git a/Documentation/fpga/fpga-region.txt
b/Documentation/fpga/fpga-region.txt
index 139a02ba1ff6..d38fa3b4154a 100644
--- a/Documentation/fpga/fpga-region.txt
+++ b/Documentation/fpga/fpga-region.txt
@@ -42,8 +42,7 @@ The FPGA region API
To register or unregister a region:
---
- int fpga_region_register(struct device *dev,
-struct fpga_region *region);
+ int fpga_region_register(struct fpga_region *region);
int fpga_region_unregister(struct fpga_region *region);
An example of usage can be seen in the probe function of [3]
diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c
index f634a8ed5e2c..b3ba3e40c44b 100644
--- a/drivers/fpga/fpga-region.c
+++ b/drivers/fpga/fpga-region.c
@@ -167,18 +167,36 @@ int fpga_region_program_fpga(struct fpga_region *region)
}
EXPORT_SYMBOL_GPL(fpga_region_program_fpga);
-int fpga_region_register(struct device *dev, struct fpga_region *region)
+/**
+ * fpga_region_create - alloc and init a struct fpga_region
+ * @dev: device parent
+ * @mgr: manager that programs this region
+ * @get_bridges: optional function to get bridges to a list
+ *
+ * Return: struct fpga_region or NULL
+ */
+struct fpga_region
+*fpga_region_create(struct device *dev,
+ struct fpga_manager *mgr,
+ int (*get_bridges)(struct fpga_region *))
{
+ struct fpga_region *region;
int id, ret = 0;
+ region = kzalloc(sizeof(*region), GFP_KERNEL);
+ if (!region)
+ return NULL;
+
id = ida_simple_get(&fpga_region_ida, 0, 0, GFP_KERNEL);
if (id < 0)
- return id;
+ goto err_free;
+ region->mgr = mgr;
+ region->get_bridges = get_bridges;
mutex_init(®ion->mutex);
INIT_LIST_HEAD(®ion->bridge_list);
+
device_initialize(®ion->dev);
- region->dev.groups = region->groups;
region->dev.class = fpga_region_class;
region->dev.parent = dev;
region->dev.of_node = dev->of_node;
@@ -188,23 +206,47 @@ int fpga_region_register(struct device *dev, struct
fpga_region *region)
if (ret)
goto err_remove;
- ret = device_add(®ion->dev);
- if (ret)
- goto err_remove;
-
- return 0;
+ return region;
err_remove:
ida_simple_remove(&fpga_region_ida, id);
- return ret;
+err_free:
+ kfree(region);
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(fpga_region_create);
+
+/**
+ * fpga_region_free - free a struct fpga_region
+ * @region: FPGA region created by fpga_region_create
+ */
+void fpga_region_free(struct fpga_region *region)
+{
+ ida_simple_remove(&fpga_region_ida, region->dev.id);
+ kfree(region);
+}
+EXPORT_SYMBOL_GPL(fpga_region_free);
+
+/*
+ * fpga_region_register - register a FPGA region
+ * @region: FPGA region created by fpga_region_create
+ * Return: 0 or -errno
+ */
+int fpga_region_register(struct fpga_region *region)
+{
+ return device_add(®ion->dev);
+
}
EXPORT_SYMBOL_GPL(fpga_region_register);
-int fpga_region_unregister(struct fpga_region *region)
+/*
+ * fpga_region_unregister - unregister a FPGA region
+ * @region: FPGA region
+ */
+void fpga_region_unregister(struct fpga_region *region)
{
device_unregister(®ion->dev);
-
- return 0;
}
EXPORT_SYMBOL_GPL(fpga_region_unregister);
@@ -212,7 +254,7 @@ static void fpga_region_dev_release(struct device *dev)
{
struct fpga_region *region = to_fpga_region(dev);
- ida_simple_remove(&fpga_region_ida, region->dev.id);
+ fpga_region_free(region);
}
/**
diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c
index 35e7e8c4a0cb..9d681a1c5738 100644
--- a/drivers/fpga/of-fpga-region.c
+++ b/drivers/fpga/of-fpga-region.c
@@ -422,20 +422,15 @@ static int of_fpga_region
[PATCH 2/4] fpga: manager: change api, don't use drvdata
From: Alan Tull
Change fpga_mgr_register to not set or use drvdata. This supports
the case where a PCIe device has more than one manager.
Add fpga_mgr_create/free functions. Change fpga_mgr_register and
fpga_mgr_unregister functions to take the mgr struct as their only
parameter.
struct fpga_manager *fpga_mgr_create(struct device *dev,
const char *name,
const struct fpga_manager_ops *mops,
void *priv);
void fpga_mgr_free(struct fpga_manager *mgr);
int fpga_mgr_register(struct fpga_manager *mgr);
void fpga_mgr_unregister(struct fpga_manager *mgr);
Update the drivers that call fpga_mgr_register with the new API.
Signed-off-by: Alan Tull
[Moritz: Fixup whitespace issue]
Reported-by: Jiuyue Ma
Signed-off-by: Moritz Fischer
---
Documentation/fpga/fpga-mgr.txt | 35 ++
drivers/fpga/altera-cvp.c| 19 ++--
drivers/fpga/altera-pr-ip-core.c | 18 +++-
drivers/fpga/altera-ps-spi.c | 20 ++--
drivers/fpga/fpga-mgr.c | 78 +---
drivers/fpga/ice40-spi.c | 21 +++--
drivers/fpga/machxo2-spi.c | 20 ++--
drivers/fpga/socfpga-a10.c | 14 --
drivers/fpga/socfpga.c | 19 ++--
drivers/fpga/ts73xx-fpga.c | 20 ++--
drivers/fpga/xilinx-spi.c| 20 ++--
drivers/fpga/zynq-fpga.c | 14 --
include/linux/fpga/fpga-mgr.h| 10 ++--
13 files changed, 237 insertions(+), 71 deletions(-)
diff --git a/Documentation/fpga/fpga-mgr.txt b/Documentation/fpga/fpga-mgr.txt
index cc6413ed6fc9..86b6df66a905 100644
--- a/Documentation/fpga/fpga-mgr.txt
+++ b/Documentation/fpga/fpga-mgr.txt
@@ -63,17 +63,23 @@ The user should call fpga_mgr_lock and verify that it
returns 0 before
attempting to program the FPGA. Likewise, the user should call
fpga_mgr_unlock when done programming the FPGA.
+To alloc/free a FPGA manager struct:
+
+
+ struct fpga_manager *fpga_mgr_create(struct device *dev,
+const char *name,
+const struct fpga_manager_ops
*mops,
+void *priv);
+ void fpga_mgr_free(struct fpga_manager *mgr);
To register or unregister the low level FPGA-specific driver:
-
- int fpga_mgr_register(struct device *dev, const char *name,
- const struct fpga_manager_ops *mops,
- void *priv);
+ int fpga_mgr_register(struct fpga_manager *mgr);
- void fpga_mgr_unregister(struct device *dev);
+ void fpga_mgr_unregister(struct fpga_manager *mgr);
-Use of these two functions is described below in "How To Support a new FPGA
+Use of these functions is described below in "How To Support a new FPGA
device."
@@ -148,6 +154,7 @@ static int socfpga_fpga_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct socfpga_fpga_priv *priv;
+ struct fpga_manager *mgr;
int ret;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -157,13 +164,25 @@ static int socfpga_fpga_probe(struct platform_device
*pdev)
/* ... do ioremaps, get interrupts, etc. and save
them in priv... */
- return fpga_mgr_register(dev, "Altera SOCFPGA FPGA Manager",
-&socfpga_fpga_ops, priv);
+ mgr = fpga_mgr_create(dev, "Altera SOCFPGA FPGA Manager",
+ &socfpga_fpga_ops, priv);
+ if (!mgr)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, mgr);
+
+ ret = fpga_mgr_register(mgr);
+ if (ret)
+ fpga_mgr_free(mgr);
+
+ return ret;
}
static int socfpga_fpga_remove(struct platform_device *pdev)
{
- fpga_mgr_unregister(&pdev->dev);
+ struct fpga_manager *mgr = platform_get_drvdata(pdev);
+
+ fpga_mgr_unregister(mgr);
return 0;
}
diff --git a/drivers/fpga/altera-cvp.c b/drivers/fpga/altera-cvp.c
index 77b04e4b3254..dd4edd8f22ce 100644
--- a/drivers/fpga/altera-cvp.c
+++ b/drivers/fpga/altera-cvp.c
@@ -401,6 +401,7 @@ static int altera_cvp_probe(struct pci_dev *pdev,
const struct pci_device_id *dev_id)
{
struct altera_cvp_conf *conf;
+ struct fpga_manager *mgr;
u16 cmd, val;
int ret;
@@ -452,16 +453,24 @@ static int altera_cvp_probe(struct pci_dev *pdev,
snprintf(conf->mgr_name, sizeof(conf->mgr_name), "%s @%s",
ALTERA_CVP_MGR_NAME, pci_name(pdev));
- ret = fpga_mgr_register(&pdev->dev, conf->mgr_name,
- &altera_cvp_ops, conf);
- if (ret)
+ mgr = fpga_mgr_create(&pdev->dev, conf->mgr_name,
+ &altera_cvp_ops, conf);
+ if (!mgr)
+ return -
[PATCH 0/4] FPGA Manager Patches for 4.18
Hi Greg, Here's Alan's reworked patchset changing the API for creating and registering FPGA Managers, Bridges and Regions following your suggestions on the API. These go on top of Paolo and Alan's patches that you queued up the other day. Thanks, Moritz Alan Tull (4): fpga: region: don't use drvdata in common fpga code fpga: manager: change api, don't use drvdata fpga: bridge: change api, don't use drvdata fpga: region: change api, add fpga_region_create/free Documentation/fpga/fpga-mgr.txt | 35 ++--- Documentation/fpga/fpga-region.txt | 3 +- drivers/fpga/altera-cvp.c | 19 +-- drivers/fpga/altera-fpga2sdram.c| 21 ++-- drivers/fpga/altera-freeze-bridge.c | 22 ++-- drivers/fpga/altera-hps2fpga.c | 24 +++-- drivers/fpga/altera-pr-ip-core.c| 18 ++- drivers/fpga/altera-ps-spi.c| 20 ++-- drivers/fpga/fpga-bridge.c | 70 +- drivers/fpga/fpga-mgr.c | 78 +++-- drivers/fpga/fpga-region.c | 69 +++-- drivers/fpga/ice40-spi.c| 21 ++-- drivers/fpga/machxo2-spi.c | 20 ++-- drivers/fpga/of-fpga-region.c | 14 +++--- drivers/fpga/socfpga-a10.c | 14 -- drivers/fpga/socfpga.c | 19 +-- drivers/fpga/ts73xx-fpga.c | 20 ++-- drivers/fpga/xilinx-pr-decoupler.c | 22 ++-- drivers/fpga/xilinx-spi.c | 20 ++-- drivers/fpga/zynq-fpga.c| 14 -- include/linux/fpga/fpga-bridge.h| 9 ++-- include/linux/fpga/fpga-mgr.h | 10 ++-- include/linux/fpga/fpga-region.h| 11 ++-- 23 files changed, 429 insertions(+), 144 deletions(-) -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] fpga: region: don't use drvdata in common fpga code
From: Alan Tull Changes to fpga_region_register function to not set drvdata. Setting drvdata is fine for DT based devices that will have one region per platform device. However PCIe based devices may have multiple FPGA regions under one PCIe device. Without these changes, the PCIe solution has to create an extra device for each child region to hold drvdata. Signed-off-by: Alan Tull Reported-by: Jiuyue Ma Signed-off-by: Moritz Fischer --- drivers/fpga/fpga-region.c| 1 - drivers/fpga/of-fpga-region.c | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c index cb0603e07ff8..f634a8ed5e2c 100644 --- a/drivers/fpga/fpga-region.c +++ b/drivers/fpga/fpga-region.c @@ -183,7 +183,6 @@ int fpga_region_register(struct device *dev, struct fpga_region *region) region->dev.parent = dev; region->dev.of_node = dev->of_node; region->dev.id = id; - dev_set_drvdata(dev, region); ret = dev_set_name(®ion->dev, "region%d", id); if (ret) diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c index 119ff75522f1..35e7e8c4a0cb 100644 --- a/drivers/fpga/of-fpga-region.c +++ b/drivers/fpga/of-fpga-region.c @@ -438,6 +438,7 @@ static int of_fpga_region_probe(struct platform_device *pdev) goto eprobe_mgr_put; of_platform_populate(np, fpga_region_of_match, NULL, ®ion->dev); + dev_set_drvdata(dev, region); dev_info(dev, "FPGA Region probed\n"); -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] fpga: bridge: change api, don't use drvdata
From: Alan Tull
Change fpga_bridge_register to not set drvdata. This is to support
the case where a PCIe device can have more than one bridge.
Add API functions to create/free the fpga bridge struct. Change
fpga_bridge_register/unregister to take FPGA bridge struct as
the only parameter.
struct fpga_bridge
*fpga_bridge_create(struct device *dev, const char *name,
const struct fpga_bridge_ops *br_ops,
void *priv);
void fpga_bridge_free(struct fpga_bridge *br);
int fpga_bridge_register(struct fpga_bridge *br);
void fpga_bridge_unregister(struct fpga_bridge *br);
Update the drivers that call fpga_bridge_register with the new API.
Signed-off-by: Alan Tull
Reported-by: Jiuyue Ma
Signed-off-by: Moritz Fischer
---
drivers/fpga/altera-fpga2sdram.c| 21 ++---
drivers/fpga/altera-freeze-bridge.c | 22 +++--
drivers/fpga/altera-hps2fpga.c | 24 +++---
drivers/fpga/fpga-bridge.c | 70 +++--
drivers/fpga/xilinx-pr-decoupler.c | 22 ++---
include/linux/fpga/fpga-bridge.h| 9 ++--
6 files changed, 123 insertions(+), 45 deletions(-)
diff --git a/drivers/fpga/altera-fpga2sdram.c b/drivers/fpga/altera-fpga2sdram.c
index d4eeb74388da..5a29ab6e3b28 100644
--- a/drivers/fpga/altera-fpga2sdram.c
+++ b/drivers/fpga/altera-fpga2sdram.c
@@ -106,6 +106,7 @@ static int alt_fpga_bridge_probe(struct platform_device
*pdev)
{
struct device *dev = &pdev->dev;
struct alt_fpga2sdram_data *priv;
+ struct fpga_bridge *br;
u32 enable;
struct regmap *sysmgr;
int ret = 0;
@@ -131,10 +132,18 @@ static int alt_fpga_bridge_probe(struct platform_device
*pdev)
/* Get f2s bridge configuration saved in handoff register */
regmap_read(sysmgr, SYSMGR_ISWGRP_HANDOFF3, &priv->mask);
- ret = fpga_bridge_register(dev, F2S_BRIDGE_NAME,
- &altera_fpga2sdram_br_ops, priv);
- if (ret)
+ br = fpga_bridge_create(dev, F2S_BRIDGE_NAME,
+ &altera_fpga2sdram_br_ops, priv);
+ if (!br)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, br);
+
+ ret = fpga_bridge_register(br);
+ if (ret) {
+ fpga_bridge_free(br);
return ret;
+ }
dev_info(dev, "driver initialized with handoff %08x\n", priv->mask);
@@ -146,7 +155,7 @@ static int alt_fpga_bridge_probe(struct platform_device
*pdev)
(enable ? "enabling" : "disabling"));
ret = _alt_fpga2sdram_enable_set(priv, enable);
if (ret) {
- fpga_bridge_unregister(&pdev->dev);
+ fpga_bridge_unregister(br);
return ret;
}
}
@@ -157,7 +166,9 @@ static int alt_fpga_bridge_probe(struct platform_device
*pdev)
static int alt_fpga_bridge_remove(struct platform_device *pdev)
{
- fpga_bridge_unregister(&pdev->dev);
+ struct fpga_bridge *br = platform_get_drvdata(pdev);
+
+ fpga_bridge_unregister(br);
return 0;
}
diff --git a/drivers/fpga/altera-freeze-bridge.c
b/drivers/fpga/altera-freeze-bridge.c
index 6159cfcf78a2..fa4b693cf4be 100644
--- a/drivers/fpga/altera-freeze-bridge.c
+++ b/drivers/fpga/altera-freeze-bridge.c
@@ -221,8 +221,10 @@ static int altera_freeze_br_probe(struct platform_device
*pdev)
struct device_node *np = pdev->dev.of_node;
void __iomem *base_addr;
struct altera_freeze_br_data *priv;
+ struct fpga_bridge *br;
struct resource *res;
u32 status, revision;
+ int ret;
if (!np)
return -ENODEV;
@@ -254,13 +256,27 @@ static int altera_freeze_br_probe(struct platform_device
*pdev)
priv->base_addr = base_addr;
- return fpga_bridge_register(dev, FREEZE_BRIDGE_NAME,
- &altera_freeze_br_br_ops, priv);
+ br = fpga_bridge_create(dev, FREEZE_BRIDGE_NAME,
+ &altera_freeze_br_br_ops, priv);
+ if (!br)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, br);
+
+ ret = fpga_bridge_register(br);
+ if (ret) {
+ fpga_bridge_free(br);
+ return ret;
+ }
+
+ return 0;
}
static int altera_freeze_br_remove(struct platform_device *pdev)
{
- fpga_bridge_unregister(&pdev->dev);
+ struct fpga_bridge *br = platform_get_drvdata(pdev);
+
+ fpga_bridge_unregister(br);
return 0;
}
diff --git a/drivers/fpga/altera-hps2fpga.c b/drivers/fpga/altera-hps2fpga.c
index 406d2f10741f..e4d39f0a7572 100644
--- a/drivers/fpga/altera-hps2fpga.c
+++ b/drivers/fpga/altera-hps2fpga.c
@@ -139,6 +139,7 @@ static int alt_fpga_bridge_probe(struct platform_device
*pdev)
struct device *dev = &pdev->dev;
[PATCH] Documentation: driver-api: fix device_connection.rst kernel-doc error
From: Randy Dunlap Using incorrect :functions: syntax (extra space) causes an odd kernel-doc warning, so fix that. Documentation/driver-api/device_connection.rst:42: ERROR: Error in "kernel-doc" directive: Signed-off-by: Randy Dunlap Cc: Heikki Krogerus --- Documentation/driver-api/device_connection.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20180426.orig/Documentation/driver-api/device_connection.rst +++ linux-next-20180426/Documentation/driver-api/device_connection.rst @@ -40,4 +40,4 @@ API --- .. kernel-doc:: drivers/base/devcon.c - : functions: device_connection_find_match device_connection_find device_connection_add device_connection_remove + :functions: device_connection_find_match device_connection_find device_connection_add device_connection_remove -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] perf: uncore: Adding documentation for ThunderX2 pmu uncore driver
On Fri, Apr 27, 2018 at 2:25 AM, Randy Dunlap wrote: > Hi, > > Just a few typo corrections... > > On 04/25/2018 02:00 AM, Ganapatrao Kulkarni wrote: >> Documentation for the UNCORE PMUs on Cavium's ThunderX2 SoC. >> The SoC has PMU support in its L3 cache controller (L3C) and in the >> DDR4 Memory Controller (DMC). >> >> Signed-off-by: Ganapatrao Kulkarni >> --- >> Documentation/perf/thunderx2-pmu.txt | 66 >> >> 1 file changed, 66 insertions(+) >> create mode 100644 Documentation/perf/thunderx2-pmu.txt >> >> diff --git a/Documentation/perf/thunderx2-pmu.txt >> b/Documentation/perf/thunderx2-pmu.txt >> new file mode 100644 >> index 000..9e9f535 >> --- /dev/null >> +++ b/Documentation/perf/thunderx2-pmu.txt >> @@ -0,0 +1,66 @@ >> + >> +Cavium ThunderX2 SoC Performance Monitoring Unit (PMU UNCORE) >> +== >> + >> +ThunderX2 SoC PMU consists of independent system wide per Socket PMUs such >> +as Level 3 Cache(L3C) and DDR4 Memory Controller(DMC). >> + >> +It has 8 independent DMC PMUs to capture performance events corresponding >> +to 8 channels of DDR4 Memory Controller. There are 16 independent L3C PMUs >> +to capture events corresponding to 16 tiles of L3 cache. Each PMU supports >> +up to 4 counters. >> + >> +Counters are independent programmable and can be started and stopped > > independently thanks, will update. > >> +individually. Each counter can be set to sample specific perf events. >> +Counters are 32 bit and does not support overflow interrupt, they are > >do notinterrupt; they are > > >> +sampled at every 2 seconds. The Counters register access are multiplexed >> +across channels of DMC and L3C. The muxing(select channel) is done through >> +write to a Secure register using smcc calls. >> + >> +PMU UNCORE (perf) driver: >> + >> +The thunderx2-pmu driver registers several perf PMUs for DMC and L3C >> devices. >> +Each of the PMU provides description of its available events > > of the PMUs > >> +and configuration options in sysfs. >> + see /sys/devices/uncore_ >> + >> +S is socket id and X represents channel number. >> +Each PMU can be used to sample up to 4 events simultaneously. >> + >> +The "format" directory describes format of the config (event ID). >> +The "events" directory provides configuration templates for all >> +supported event types that can be used with perf tool. >> + >> +For example, "uncore_dmc_0_0/cnt_cycles/" is an >> +equivalent of "uncore_dmc_0_0/config=0x1/". >> + >> +Each perf driver also provides a "cpumask" sysfs attribute, which contains a >> +single CPU ID of the processor which is likely to be used to handle all the >> +PMU events. It will be the first online CPU from the NUMA node of PMU >> device. >> + >> +Example for perf tool use: >> + >> +perf stat -a -e \ >> +uncore_dmc_0_0/cnt_cycles/,\ >> +uncore_dmc_0_1/cnt_cycles/,\ >> +uncore_dmc_0_2/cnt_cycles/,\ >> +uncore_dmc_0_3/cnt_cycles/,\ >> +uncore_dmc_0_4/cnt_cycles/,\ >> +uncore_dmc_0_5/cnt_cycles/,\ >> +uncore_dmc_0_6/cnt_cycles/,\ >> +uncore_dmc_0_7/cnt_cycles/ sleep 1 >> + >> +perf stat -a -e \ >> +uncore_dmc_0_0/cancelled_read_txns/,\ >> +uncore_dmc_0_0/cnt_cycles/,\ >> +uncore_dmc_0_0/consumed_read_txns/,\ >> +uncore_dmc_0_0/data_transfers/ sleep 1 >> + >> +perf stat -a -e \ >> +uncore_l3c_0_0/l3_retry/,\ >> +uncore_l3c_0_0/read_hit/,\ >> +uncore_l3c_0_0/read_request/,\ >> +uncore_l3c_0_0/inv_request/ sleep 1 >> + >> +The driver does not support sampling, therefore "perf record" will >> +not work. Per-task (without "-a") perf sessions are not supported. >> > > > -- > ~Randy thanks Ganapat -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
