spelling: its

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

src/fw/applib/ui/dialogs/actionable_dialog.h

@@ -53,7 +53,7 @@ void actionable_dialog_set_action_bar_type(ActionableDialog *actionable_dialog,
                                            ActionBarLayer *action_bar);
 
 //! Sets the ClickConfigProvider of the action bar. If the dialog has a custom action bar then
-//! this function has no effect. The action bar is responsible for setting up it's own click
+//! this function has no effect. The action bar is responsible for setting up its own click
 //! config provider
 //! @param actionable_dialog Pointer to a \ref ActionableDialog to which to set the provider on
 //! @param click_config_provider The \ref ClickConfigProvider to set

src/fw/applib/ui/progress_window.h

@@ -27,7 +27,7 @@
 //!
 //! A UI component that is a window that contains a progress bar. The state of the progress bar
 //! is updated using progress_window_set_progress. When the window is first pushed, the progress
-//! bar will fill on it's own, faking progress until the max_fake_progress_percent threshold is
+//! bar will fill on its own, faking progress until the max_fake_progress_percent threshold is
 //! hit. Once the client wishes to indicate success or failure, calling
 //! progress_window_set_progress_success or progress_window_set_progress_failure will cause the
 //! UI to animate out to indicate the result, followed by calling the .finished callback if

src/fw/debug/legacy/flash_logging.c

@@ -36,11 +36,11 @@
 //! Logs messages to SPI flash for later retreival.
 //!
 //! The different chunks allow us to implement a rolling log, where if we fill up all the chunks, we can erase the oldest
-//! chunk to find us some more space. Each chunk gets it's own header at the top of the chunk to indicate the order in
+//! chunk to find us some more space. Each chunk gets its own header at the top of the chunk to indicate the order in
 //! which the chunks should be reassembled.
 
 //! Make sure chunks are still an even number of flash subsectors. Our log space is 7 subsectors, so our NUM_CHUNKS
-//! makes it so each chunk has it's own subsector.
+//! makes it so each chunk has its own subsector.
 #define NUM_CHUNKS 7
 
 #define CHUNK_SIZE_BYTES (SECTION_LOGS_SIZE_BYTES / NUM_CHUNKS)

src/idl/nanopb/payload.proto

@@ -17,7 +17,7 @@ Payloads are how data should be sent and collected from devices. A simple
 normal flow would be for a watch to generate Events and Measurements,
 bundle them into a Payload that is sent to mobile. Mobile would then take that
 payload, as well as events and measurements generated on the mobile device
-itself, and bundle them into it's own Payload message to send to the
+itself, and bundle them into its own Payload message to send to the
 Pipeline API
 
 More complex patterns occur when the watch sends mupltiple Payloads, at