**** BEGIN LOGGING AT Sat Jul 13 02:59:57 2019
Jul 13 10:56:33 <pratimugale[m]> <Abhishek_1 "pratimugale: Another good exampl"> abhishek_:  Hi, I started working with the stepper motor and was able to control it using the PRU.  I just wanted to make sure that
Jul 13 10:57:53 <pratimugale[m]> Is there anything else you had in mind?
Jul 13 12:10:04 <vaishnav98_[m]> jkridner mdp ravikp7: I was trying to implement of_bus struct instance for greybus as suggested by mdp , it would be really helpful if you could help me with some of my doubts,
Jul 13 12:10:05 <vaishnav98_[m]> 1) shouldn't I be adding the of_bus struct instance for greybus here: https://github.com/beagleboard/linux/blob/f45281297c419d29df9bedbb9d1eaeb12fd2b93b/drivers/of/address.c#L415 , how should the .map and . translate methods be modified for greybus
Jul 13 12:10:11 <vaishnav98_[m]> 2)after adding a of_bus struct for greybus, isn't an implementation similar to https://github.com/beagleboard/linux/blob/4.14/drivers/of/of_pci.crequired for greybus, here other than of_pci(greybus)_find_child_device what all methods do i need to include?
Jul 13 12:10:40 <vaishnav98_[m]> 3)on the greybus driver side , should an implementation similar to https://github.com/beagleboard/linux/blob/4.14/drivers/pci/of.c(pci(gb)_set_of_node and pci(gb)_release_of_node suffice and then get the platform data from the of_node and supply it in the spi_new_device and i2c_new_device calls in the gb_spi and gb_i2c drivers?
Jul 13 12:11:34 <vaishnav98_[m]> Is my understanding of mdp 's suggestion correct, can you please guide me in the correct direction as i don't have much previous experience modifying kernel drivers.
Jul 13 16:05:15 <embden[m]> julieng:  I was also wondering whether the secondary IRQ creates new security risks.
Jul 13 16:33:55 <julieng[m]> <embden[m] "julieng:  I was also wondering w"> Dom0 is considered trusted. But even it wasn't trusted, virtualizing the interrupt controller allows you to sanitize the value
Jul 13 16:34:14 <julieng[m]> So I don't see any potential security risk
Jul 13 16:42:21 <embden[m]> julieng:  what to do if two domU would want to remap the interrupts in the crossbar?
Jul 13 16:44:56 <embden[m]> I am also interested why the output from dom0 has disappeared after I added my code
Jul 13 16:51:58 <embden[m]> hm. this is strange. When I got xen_bootargs : setenv xen_bootargs 'dom0_mem=512M' then I had the error that irq can't be obtained but after applying my code it doesn't show any output from dom0
Jul 13 16:52:57 <embden[m]> but why I have xen_bootargs: 'dom0_mem=512M console=dtuart dtuart=serial0 sync_console' then I have output from dom0 and also I have this count down 3...2...1...
Jul 13 16:55:06 <embden[m]> but in the last case I have: (XEN) Looking for dtuart at "serial0", options ""<br />
Jul 13 16:55:07 <embden[m]> (XEN) Unable to initialize dtuart: -19<br />
Jul 13 16:55:08 <embden[m]> (XEN) Bad console= option 'dtuart'
Jul 13 17:00:23 <embden[m]> probably, because the default uart is serial2. So, with serial2 I also have no output from dom0
Jul 13 17:39:34 <embden[m]> julieng:  I've added the same check in handle_device so, now, the loading fails with the error: (XEN) the vIRQ number 253 is too high for domain 0 (max = 192)
Jul 13 17:39:35 <embden[m]> (XEN) Unable to map IRQ253 to dom0
Jul 13 17:39:36 <embden[m]> (XEN) Device tree generation failed (-22).
Jul 13 17:40:11 <embden[m]> which is not surprising
**** ENDING LOGGING AT Sun Jul 14 03:00:21 2019